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ABSTRACT 



A system and method for creating a graphical program, 
wherein the graphical program is operable to access capa- 
bilities of an object. During creation of the graphical 
program, the user operates to place an object node in the 
graphical program, wherein the object node is operable to 
access capabilities of the object. This preferably includes the 
user arranging on the screen the graphical program, includ- 
ing the object node and various other nodes, and connecting 
the various nodes to create the graphical program. The user 
then configures the object node to receive information on the 
object, preferably by the user configuring the object node 
with a reference to the object, e.g., a pointer, address, or 
other information which specifies the identity and/or loca- 
tion of the object. The user also selects one or more methods 
to be invoked on the object and/or one or more properties to 
get/set on the object. Once the graphical program has been 
created, then during execution of the graphical program, the 
object node accesses the capabilities of the object. 
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SYSTEM AND METHOD FOR ACCESSING Checking io a Graphical Automation Client" and filed on 

OBJECT CAPABILITIES IN A GRAPHICAL Mar. 4, 1997, whose inventors were Murali Parthasarathy 

PROGRAM and Omid Sojoodi, which issued May. 16, 2000 as U.S. Pat. 

No. 6,064,812, 

PRIORITY INFORMATION 5 tj. S . patent application Ser. No. 08/717,771 tided "Sys- 

This application claims the benefit of priority of: tem aad Method for Performing Class Checking of Objects 

U.S. Provisional Application No. 60/056,528 titled "Sys- ^ Gra ?^ Ca L ^ F1 ^^°ff ^ hic ^ ued Dec. 8, 

tem and Method for Providing Automation Server Capabili- 1998 as U ' S * Pat ' No ' 5 > 847 ' 953 Ste P hen W ' Ro *™> 

ties in Graphical Programs," by Ram Kudukoli, Robert Dye us P atent application Ser. No. 08/717,772 tided "Sys- 

and Murali Parthasarathy, hied on Aug. 21, 1997; tem and Method for Performing Interface Independent Vir- 
tual Instrumentation Functions Using Attribute Nodes in a 

CONTINUATION DATA Graphical Data Flow Program" which issued May. 18, 2000 

. 4 . . 4 , ,. , , as U.S. Pat. No. 5,905,648 and filed Sep. 23, 1996, whose 

This is a continuation-in-part of co-pending patent appli- - t ~ A > j. j 0 * tf t« n 

xt rto/mr^f ,- t i j ac* \ j » a ,i j f inventors were Omid Sojoodi and Stephen W. Rogers, 

cation Ser. No. 08/916,005 titled "System and Method for 15 

Providing Client/Server Access to Graphical Programs" RESERVATION OF COPYRIGHT 
filed on Aug. 21, 1997, whose inventors were Robert Dye 

and Omid Sojoodi which issued Aug. 15, 2000 as U.S. Pat. A portion of the disclosure of this patent document 

No. 6,102,965 which is a continuation in part of co-pending contains material to which a claim of copyright protection is 

patent application Ser. No. 08/810,079 titled "System and 20 made. The copyright owner has no objection to the facsimile 

Method for Developing Automation Clients using a Graphi- reproduction by anyone of the patent document or the patent 

cal Data Flow Program" filed on Mar. 4, 1997, whose disclosure as it appears in the Patent and Trademark Office 

inventors were Murali Parthasarathy and Omid Sojoodi, patent file or records, but reserves all other rights whatso- 

which issued May 16, 2000 as U.S. Pat. No. 6,064,812 ever, 

which is a continuation-in-part of co-pending application 25 

Ser. No. 08/717,771 which issued Dec. 8, 1998 as U.S. Pat. FIELD OF THE INVENTION 

No. 5,847,953 titled "System and Method for Performing The nl iDventioD relates to hical pr0 g rammiDg) 

Class Checking of Objects m a Graphical Data Flow Pro- and in particular to a system for creating graphical programs, 

gram and filed Sep. 23 ,,1996, whose mventors were Omid wfaerein the hical ro ^ ams are able t0 access 

Sojoodi and Stephen W. Rogers, which issued Dec. 8,1998 30 mnctionality or properties of objects. 

as U.S. Pat. No. 5,847,953. 3 

This is also a continuation in part of co-pending patent DESCRIPTION OF THE RELATED ART 

application Ser. No. 08/810,079 titled "System and Method ^ , 

for Developing Automation Clients using a Graphical Data Traditionary, high level text-based programming lan- 
Flow Program- filed on Mar. 4, 1997, whose inventors were 35 ^ages have been used by programmers in writing applica- 
Murali Parthasarathy and Omid Sojoodi, which issued May. * ons P ro S rams - M f V dlfi *re n high level programming 
16, 2000 as U.S. Pat. No. 6,064,812 which is a continuation- S ^ mcludm S BASIC > C > FORTRAN, Pascal, 
in-part of co-pending application Ser. No. 08/717,771 tided ^OB^L, ADA, APL, etc. Programs written in these high 
"System and Method for Performing Class Checking of [ evel are translated to the ^machine language level 
Objects in a Graphical Data Flow Program" and filed Sep. 40 *>y translators known as compters. The high level program- 
23, 1996, whose inventors were Omid Sojoodi and Stephen mm & ^f^ 5 ™ ^ level, as well as the assembly 
W. Rogers which issued Dec. 8, 1998 as U.S. Pat. No. level > are referred to as text-based programming 
5 847 953 environments. 

' Thfe is also a continuation-in-part of co-pending applica- Increasingly computers are required to be used and pro- 
tion Ser. No. 08/717,771 titled "System and Method for 45 grammed b ? ^ who ar * ° ot ^ tram f d ] c '^P^ 
Performing Class Checking of Objects in a Graphical Data P ro S rammi *g techniques. When traditional text-based pro- 
Flow Program" and filed Sep. 23, 1996, whose inventors BP™™f environments are used the user's programming 
were Omid Sojoodi and Stephen W. Rogers which issued ^ and ^ to ^teract with the computer system often 
Dec 8 1998 as U S Pat No 5 847 953 become a limiting factor m the achievement of optimal 
' •*••>>• 5Q utilization of the computer system. 

CROSS-REFERENCE TO RELATED There are numerous subtle complexities which a user 

APPLICATIONS must master before he/she can efficiently program a com- 

c u • i- »■ i * j A A i_ * puter system in a text-based environment. The task of 

Ine to Rowing applications are related to the present „ • 4 , A 

a lication* programming a computer system to model a process often is 

. * 55 further complicated by the fact that a sequence of math- 

U.S. patent application Ser. No. 08/916,005 titled "Sys- ematical formulaSj mathematical steps or other procedures 

tem and Method for Providing Client/Server Access to customarily used to conceptually model a process often does 

Graphical Programs" filed on Aug. 21, 1997, whose inven- not closely t0 tbe traditiona i text-based program- 

T T 6 ? ~ S ° J00dl WhlCh isSaed AUg - min 8 techniques used to program a computer system to 

15, 2000 as U.S. Pat. No. 6,102,965; 60 model such a process Jn Qther word ^ the requirement that 

U.S. patent application Ser. No. 08/810,079 tided "Sys- a user program in a text-based programming environment 

tem and Method for Developing Automation Clients using a places a level of abstraction between the user's conceptu- 

Graphical Data Flow Program" filed on Mar. 4, 1997, whose alization of the solution and the implementation of a method 

inventors were Murali Parthasarathy and Omid Sojoodi, that accomplishes this solution in a computer program, 

which issued May. 16, 2000 as U.S. Pat. No. 6,064,812, 65 Thus, a user often must substantially master different skills 

U.S. patent application Ser. No. 08/811,187 titled "System in order to both conceptually model a system and then to 

and Method for Performing Class Propagation and Type program a computer to model that system. Since a user often 
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is not fully proficient in techniques for programming a 
computer system in a text-based environment to implement 
his model, the efficiency with which the computer system 
can be utilized to perform such modeling often is reduced. 

Examples of fields in which computer systems are 5 
employed to model and/or control physical systems are the 
fields of instrumentation, process control, and industrial 
automation. Computer modeling or control of devices such 
as instruments or industrial automation hardware has 
become increasingly desirable in view of the increasing 10 
complexity and variety of instruments and devices available 
for use. However, due to the wide variety of possible 
testing/control situations and environments, and also the 
wide array of instruments or devices available, it is often 
necessary for a user to develop a program to control a ^ 
desired system. As discussed above, computer programs 
used to control such systems had to be written in conven- 
tional text-based programming languages such as, for 
example, assembly language, C, FORTRAN, BASIC, or 
Pascal. Traditional users of these systems, however, often 2 o 
were not highly trained in programming techniques and, in 
addition, traditional text -based programming languages 
were not sufficiently intuitive to allow users to use these 
languages without training. Therefore, implementation of 
such systems frequently required the involvement of a 25 
programmer to write software for control and analysis of 
instrumentation or industrial automation data. Thus, devel- 
opment and maintenance of the software elements in these 
systems often proved to be difficult. 

U.S. Pat. No. 4,901,221 to Kodosky et al discloses a 30 
graphical system and method for modeling a process, i.e., a 
graphical programming environment, which enables a user 
to easily and intuitively model a process. The graphical 
programming environment disclosed in Kodosky et al can be 
considered the highest and most intuitive way in which to 35 
interact with a computer. A graphically based programming 
environment can be represented at level above text-based 
high level programming languages such as C, Pascal, etc. 
The method disclosed in Kodosky et al allows a user to 
construct a diagram using a block diagram editor, such that 40 
the diagram created graphically displays a procedure or 
method for accomplishing a certain result, such as manipu- 
lating one or more input variables to produce one or more 
output variables. In response to the user constructing a data 
flow diagram or graphical program using the block diagram 45 
editor, machine language instructions are automatically con- 
structed which characterize an execution procedure which 
corresponds to the displayed procedure. Therefore, a user 
can create a computer program solely by using a graphically 
based programming environment. This graphically based 50 
prograrnrning environment may be used for creating virtual 
instrumentation systems, industrial automation systems and 
modeling processes, as well as for any type of general 
programming. 

Therefore, Kodosky et al teaches a graphical program- 55 
ming environment wherein a user places or manipulates 
icons in a block diagram using a block diagram editor to 
create a data flow "program/' A graphical program for 
controlling or modeling devices, such as instruments, pro- 
cesses or industrial automation hardware, is referred to as a 60 
virtual instrument (VI). In creating a virtual instrument, a 
user preferably creates a front panel or user interface panel. 
The front panel includes various front panel objects, such as 
controls or indicators that represent the respective input and 
output that will be used by the graphical program or VI, and 65 
may include other icons which represent devices being 
controlled. When the controls and indicators are created in 
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the front panel, corresponding icons or terminals are auto- 
matically created in the block diagram by the block diagram 
editor. Alternatively, the user can first place terminal icons in 
the block diagram which cause the display of corresponding 
front panel objects in the front panel. The user then chooses 
various functions that accomplish his desired result, con- 
necting the corresponding function icons between the ter- 
minals of the respective controls and indicators. In other 
words, the user creates a data flow program, referred to as a 
block diagram, representing the graphical data flow which 
accomplishes his desired function. This is done by wiring up 
the various function icons between the control icons and 
indicator icons. The manipulation and organization of icons 
in turn produces machine language that accomplishes the 
desired method or process as shown in the block diagram. 

A user inputs data to a virtual instrument using front panel 
controls. This input data propagates through the data flow 
block diagram or graphical program and appears as changes 
on the output indicators. In an instrumentation application, 
the front panel can be analogized to the front panel of an 
instrument. In an industrial automation application the front 
panel can be analogized to the MMI (Man Machine 
Interface) of a device. The user adjusts the controls on the 
front panel to affect the input and views the output on the 
respective indicators. 

Thus, graphical programming has become a powerful tool 
available to programmers. Graphical programming environ- 
ments such as the National Instruments Lab VIEW product 
have become very popular. Tools such as Lab VIEW have 
greatly increased the productivity of programmers, and 
increasing numbers of programmers are using graphical 
programming environments to develop their software appli- 
cations. In particular, graphical programming tools are being 
used for test and measurement, data acquisition, process 
control, man machine interface (MMI), and supervisory 
control and data acquisition (SCADA) applications, among 
others. 

In parallel to the development of graphical data flow 
programming for various applications, such as virtual 
instrumentation, object and/or component technology has 
emerged in the area of software development. The notion of 
object technology relates to an application program or object 
using capabilities or services of an object. For example, 
object technology includes the notion of "servers" "export- 
ing" their "objects" for use by "clients." A server is a 
software application which makes available its classes to be 
accessed from another application, referred to as a client. A 
client instantiates objects from the classes in the type 
libraries. In addition, the term "object" also includes various 
other types of components or objects, including applications, 
which offer services or functionality that can be accessed by 
a client. 

Objects generally have properties and methods. Properties 
are the data associated with the object and typically deter- 
mine attributes of the object, such as the number of columns 
of a spreadsheet. Methods are functions or operations which 
the object is capable of performing, such as drawing a 
spreadsheet on a display screen. A server exports an object 
by making the methods and properties of the object invok- 
able by a client. 

An example of a server is Microsoft Excel® which 
exports its objects for use by clients. An example of an 
object technology is Active X, formerly called OLE (Object 
Linking and Embedding), promulgated by Microsoft. For 
example, the Microsoft Excel spreadsheet program, the 
Microsoft Access® database program, and the Microsoft 
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Word® word processing program, all export objects using output from the graphical program. Once the graphical 

the Active X interface. Active X is an industry standard program has been created, then during execution of the 

object or component interface used by application programs graphical program, the object node accesses the capabilities 

to provide objects in a consistent manner to other application Q f the object. More specifically, after creation of the graphi- 

programs, development tools, and macro languages. Other 5 ca i program, the system/method constructs execution 

examples of object technologies are OpenDoc® and the instructions in response to the graphical program, wherein 

Common Object Request Broker Architecture (CORBA). thc execution instructions are executable to access the 

It is desirable for a program, such as a graphical program, capabilities of the object. When these execution instructions 

to be able to access functionality provided by an object or are executed, the object node accesses the capabilities of the 

server. For example, often it is desirable for a program, such jo object. 

as a graphical program, to display, manipulate, catalog edit ]n the ferred embodiment the object may be any of 

or perform other operations, such as may be performed by various , of ^ such M a software objec( acco[d _ 

an object or server, on data acquired or generated by a m tQ the standard principles of object-oriented software, a . 

graphical program or virtual instrument. Foi : example, it may software nent other t of re . usable software 

be desirable for a virtual instrument to display acquired 15 elements, or an application, among others. Where the object 

temperature samples in a spreadsheet, such as a Microsoft ^ , objec , of on ent, the object node js 

Excel spreadsheet. More generally it would be desirable to executable t0 either invoke a method of th ^ 0 bject, t 

provide a system and method which enables a graphical and/or se , one or more r erties of the object 0 J r ^ 

program to be able to invoke objects, such as from a server, other capabilities of the object . where the object is a[] 

for a vanety of applications. 20 applicatioll) ^ object node ^ operable , 0 perform one or 

Therefore, improved methods are desired for enabling a more of x) m itiate execution of t h e application; or 2) get/set 

graphical data flow programming system to access objects. one or more properties of the application. Also, the object 

More particularly, an improved system and method is may reside in the same co mput er where the graphical 

desired which enables a graphical data flow program to be program is being created, or may reside in a different 

constructed which uses capabilities of objects. 25 computer connected through a network. 

SUMMARY OF THE INVENTION In the preferred embodiment, the graphical program com- 

The present invention comprises a system and method for P rises a diagram or execution portion and a user interface 

creating a graphical program, wherein the graphical program portion, and the object node is comprised in the diagram 

is operable to access capabilities of an object. The present 30 portion- Alternatively, the object node may be comprised in 

invention preferably operates in a computer including a the ^ interface portion. Id this case where the object node 

display screen and a user input device. ^ located in the user interface, the object is preferably 

During creation of the graphical program, the user oper- comprised in the object node, and the object node operates 

ates to place an object node in the graphical program, t0 manipulate the object. For example, a document may be 

wherein the object node is operable to access capabilities of 3S comprised in the object node, wherein the object node is 

the object. Stated another way, during program creation the 0 P erab ] e f° dls P la y <A ^* M 10 ^ document durin S execu " 

computer system displays on the screen an object node in the tlon of the graphical program. As another example, the 

graphical program in response to user input, wherein the ob J ect ma y h * a ?*" mte ? ace element ' such 45 a contro1 or 

object node is operable to access capabilities of the object. indicator, wherein the object node is operable to affect the 

This preferably includes the user arranging on the screen the « data 1D P ut t0 or 0Ut P ut &om the contro1 or indicator 
graphical program, including the object node. The graphical 

program will typically comprise a plurality of nodes, and the BRffiF DESC RIPT10N OF THE DRAWINGS 

method tor creating the graphical program comprises 

arranging on the screen the plurality of nodes, including the A better understanding of the present invention can be 

object node, and connecting the various nodes to create the 45 obtained when the following detailed description of the 

graphical program. In the preferred embodiment, the nodes preferred embodiment is considered in conjunction with the 

are connected in a data flow paradigm. following drawings, in which: 

The user then configures the object node to receive FIG. 1 illustrates an instrumentation control system 

information on the object, preferably by the user configuring according to one embodiment of the present invention; 

the .object node :wilh a reference to the object, e.g a pointer, 50 FIG. 1A illustrates an industrial automation system 

address or other information which specifies the identity according to one embodiment of the present invention; 

and/or location of the object. This preferably includes the „ . , , , 

user selecting a class of the object. In the preferred FIG. 2 is a block diagram of the computer of the control 

embodiment, the object node includes an object reference S ^ S em ° ' ' 

input for receiving a reference to the object, and the user ss FIG> 3 15 a block dia S ram illustrating the relationship of 

connects the object reference input of the object node to portions of the instrumentation control system of FIG. 1 

receive the reference to the object. This preferably includes according to a first embodiment; 

the user placing an object reference node in the graphical FIG. 3a is a block diagram illustrating the relationship of 

program, wherein the object reference node includes an portions of the instrumentation control system of FIG. 1 

object reference output that provides the reference to the 60 acc ording to a second embodiment; 

object, and the user connecting the object reference output FIG. 4 is a flowchart diagram illustrating creation of a 

of the object reference node to the object reference input of graphical program including an object node according to the 

the object node. The object node then receives the informa- present invention; 

tion on the object on the object reference input during FIG. 5 is a flowchart diagram illustrating execution of the 

execution of the graphical program. 6 5 graphical program created in FIG. 4, wherein the object 

Creation of the graphical program may also include node operates to access capabilities of an object according to 

configuring a user interface to display data input to and/or the present invention; 
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FIG. 6 is a screen shot illustrating the VI block diagram FIGS. 34, 35 and 36 are screen shots illustrating a help 

and front panel of an exemplary automation virtual instru- screen for an automation open node, an automation property 

ment of FIG. 3; node, and an automation invoke node, respectively. 

FIG. 7 is a screen shot illustrating the automation nodes FIG. 37 is a block diagram illustrating the relationship of 

palette; 5 portions of the instrumentation control system of FIG. 1 

FIG. 8 is a flowchart illustrating steps taken to create and according to a first embodiment; 

use a graphical automation client program of FIG. 3; FIG. 37a is a block diagram illustrating the relationship of 

FIGS. 8a, 86, and 8c are a flowchart illustrating steps portions of the instrumentation control system of FIG. 1 

taken to create and use a graphical automation client pro- where the server is located on a remote computer system; 

gram in more detail than the flowchart of FIG. 8; 10 FIG. 38 illustrates the VI Server front panel refnum 

FIG. 9 is a screen shot illustrating the automation control controls; 

refnum palette; FIGS. 3SM2 illustrate the VI Server function nodes which 

FIG. 10 is a screen shot illustrating an automation refnum can be placed in a graphical program and used for program- 
in a VI block diagram and a pop -up menu of the automation 15 matically accessing functionality of other graphical pro- 
refnum with a menu selection item for selecting an automa- gramming applications or programs; 
tion class; FIG. 43 illustrates a block diagram or graphical program 

FIG. 11 is a screen shot illustrating an exemplary list of which uses Strictly-typed VI references and utilizes the call 

the type libraries associated with the OLE Automation by reference node to call a server VI in a client VI; 

servers present in a system; 2 0 FIG. 44 illustrates a block diagram or graphical program 

FIG. 12 is a screen shot illustrating a type library browse which uses Generic VI references with the Property and 

menu selected from the pop-up menu of FIG. 10; Invoke nodes; 

FIG. 13 is a screen illustrating an automation class having FIG. 45 illustrates a block diagram or graphical program 

been chosen for the automation refnum of FIG. 10 and an which includes an Open Application node and the Property 

automation open node being wired to the automation 25 and/or Invoke nodes to access capabilities of a server 

refnum; application; 

FIG. 14 is a screen shot illustrating an automation prop- FIG. 46 is a is a screen shot illustrating the "Select 

erty node wired to the automation open node of FIG. 13 and Lab VIEW Class" submenu; 

a list of properties of the automation class which was chosen FIG. 47 is a is a screen shot illustrating the Server 

m nG - !3; 30 Configuration Dialog Box; 

FIG. 15 is a screen shot illustrating a property having been FIG. 48 is a is a screen shot illustrating the TCP/IP Access 

chosen for the automation property node of FIG. 14; Dialog Box for selecting Exported Vis; 

FIG. 16 is a screen shot illustrating an automation invoke FIG. 49 is a is a screen shot illustrating the TCP/IP Access 

node wired to the automation property node of FIG. 14 and 35 Dialog Box for selecting TCP/IP access; 

a list of methods of the automation class which was chosen FIGS , 50A _ D iriustrate how Vis and applications are 

in Hu. 14; accessed on remote computer systems according to the 

FIG. 17 is a screen shot illustrating a method having been present invention, 

chosen for the automaton invoke node of FIG. 16; Fia 51 iUustrates ActiwcX controls referred to as 

FIG. 18 is a flowchart illustrating steps taken to display an 40 ActiveX container and ActiveX variant; and 

application help screen for an automation object according F IGS. 52-54 illustrate the Insert Object dialog box for 

to the preferred embodiment of the present invention; mserting mei&nt types of objects into the ^ pand 

FIG 19 is a screen shot illustrating the step of displaying While the j nvenu0 n is susceptible to various modifica- 

a method of an automation invoke node according of the tions aod a it erna tive forms specific embodiments are shown 

flowchart of FIG. 18; 45 by way of example m the drawings md wiU nerein 5e 

FIG. 20 is a screen shot illustrating the step of displaying described in detail. It should be understood however, that 

an application help option for a method of an automation drawings and detailed description thereto are not intended to 

invoke node according of the flowchart of FIG. 18; limit the invention to the particular form disclosed. But on 

FIG. 21 is a screen shot illustrating the step of displaying the contrary the invention is to cover all modifications, 

a application help screen of the flowchart of FIG. 18; 50 equivalents and alternative following within the spirit and 

FIG. 22 is a flowchart illustrating steps taken to propagate scope of the present invention as defined by the appended 

the automation class of an automation node to another claims, 
automation node; 

FIGS. 23 through 25 are screen shots illustrating steps of J5 "S^SgSSgJS,™ 

the flowchart of FIG. 22; S5 T . PREFERRED EMBODIMENT 

riTp ~ c . a u _* -11 * . .1 . , Incorporation by Reference 

HO. 26 is a flowchart illustrating steps taken to propagate ™/ P „n„„- no r>* . j , * i- „■ 

. , c * j * 7t_ Tae following U.S. Patents and patent applications are 

the automation class of an automation node to another . . . , , . e . f. . \ r t . , 

automation node; ^ y ponied by reference in their entirety as though 

L , „ , fully and completely set forth herein. 

fl FIGS. 27 and 28 are screen shots illustrating steps of the 60 u s Pat No 4f901j221 titled "Graphical System for 

flowchart of FIG. 24; Modeling a Process and Associated Method/' issued on Feb. 

FIG. 29 is a flowchart illustrating steps taken to perform 13 1990. 

type propagation checking of automation nodes; u.S. Pat. No. 5,481,741 titled "Method and Apparatus for 

FIGS. 30 through 32 are screen shots illustrating steps of Providing Attribute Nodes in a Graphical Data Flow Envi- 

the flowchart of FIG, 29; 65 ronment". 

FIG. 33 is a flowchart illustrating in more detail the step U.S. patent application Ser. No. 08/916,005 titled "Sys- 

of FIG. 29 of performing type propagation; tem and Method for Providing Client/Server Access to 
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Graphical Programs" filed on Aug. 21, 1997, whose inven- one or more instruments of a single interface type, such as 

tors were Robert Dye and Omid Sojoodi. only GPIB instruments. 

U.S. patent application Ser. No. 08/810,079 titled "Sys- The instruments are coupled to the unit under test (UUT) 

tem and Method for Developing Automation Clients using a or process 150, or are coupled to receive field signals, 

Graphical Data Flow Program" filed on Mar. 4, 1997, whose 5 typically generated by transducers. The system 100 may be 

inventors were Murali Parthasarathy and Omid Sojoodi, used in a data acquisition and control application, in a test 

U.S. patent application Ser. No. 08/717,771 titled "Sys- and measurement application, a process control application, 

tem and Method for Performing Class Checking of Objects or a man-machine interface application, 

in a Graphical Data Flow Program" and filed Sep. 23, 1996, Referring now to FIG. 1A, an industrial automation 

whose inventors were Omid Sojoodi and Stephen W. Rog- 10 system 160 is shown. The industrial automation system 160 

ers. is similar to the instrumentation or test and measurement 

The Lab VIEW and Bridge VIEW graphical programming system 100 shown in FIG, 1. Elements which are similar or 

manuals and help files, including the "G Programming identical to elements in FIG. 1 have the same reference 

Reference Manual", available from National Instruments numerals for convenience. The system 160 comprises a 

Corporation, are also hereby incorporated by reference in 15 computer 102 which connects to one or more devices or 

their entirety. instruments. The computer 102 comprises a CPU, a display 

FIGS. 1 and 1A — Instrumentation and Industrial Automa- screen, memory, and one or more input devices such as a 

tion Systems mouse or keyboard as shown. The computer 102 connects 

Referring now to FIG. 1, an instrumentation control through the one or more devices to a process or device 150 
system 100 is shown. The system 100 comprises a host 20 to perform an automation function, such as M (Man 
computer 102 which connects to one or more instruments. Machine Interface), SCADA (Supervisory Control and Data 
The host computer 102 comprises a CPU, a display screen, Acquisition), portable or distributed data acquisition, pro- 
memory, and one or more input devices such as a mouse or cess control, advanced analysis, or other control, 
keyboard as shown. The computer 102 connects through the The one or more devices may include a data acquisition 
one or more instruments to analyze, measure or control a 25 board 114 and associated signal conditioning circuitry 124, 
unit under test (UUT) or process 150. a PXI instrument 118, a video device 132 and associated 

The one or more instruments may include a GPIB instru- image acquisition card 134, a motion control device 136 and 

ment 112 and associated GPIB interface card 122, a data associated motion control interface card 138, a fieldbus 

acquisition board 114 and associated signal conditioning device 170 and associated fieldbus interface card 172, a PLC 

circuitry 124, a VXI instrument 116, a PXI instrument 118, 30 (Programmable Logic Controller) 176, a serial instrument 

a video device 132 and associated image acquisition card 182 and associated serial interface card 184, or a distributed 

134, a motion control device 136 and associated motion data acquisition system, such as the Fieldpoint system 

control interface card 138, and/or one or more computer available from National Instruments, among other types of 

based instrument cards 142, among other types of devices. devices. 

The GPIB instrument 112 is coupled to the computer 102 35 The DAQ card 114, the PXI chassis 118, the video device 

via a GPIB interface card 122 provided by the computer 102. 132, and the image acquisition card 136 are preferably 

In a similar manner, the video device 132 is coupled to the connected to the computer 102 as described above. The 

computer 102 via the image acquisition card 134, and the serial instrument 182 is coupled to the computer 102 through 

motion control device 136 is coupled to the computer 102 a serial interface card 184, or through a serial port, such as 

through the motion control interface card 138. The data 40 an RS-232 port, provided by the computer 102. The PLC 

acquisition board 114 is coupled to the computer 102, and 176 couples to the computer 102 through a serial port, 

preferably interfaces through signal conditioning circuitry Ethernet port, or a proprietary interface. The fieldbus inter- 

124 to the UUT. The signal conditioning circuitry 124 face card 172 is preferably comprised in the computer 102 

preferably comprises an SCXI (Signal Conditioning eXten- and interfaces through a fieldbus network to one or more 

sions for Instrumentation) chassis comprising one or more 45 fieldbus devices. Each of the DAQ card 114, the serial card 

SCXI modules 126. 184, the fieldbus card 172, the image acquisition card 134, 

The GPIB card 122, the image acquisition card 134, the and the motion control card 138 are typically plugged in to 

mo tion control interface card 138, and the DAQ card 114 are an I/O slot in the computer 102 as described above, 

typically plugged in to an I/O slot in the computer 102, such However, these cards 114, 184, 172, 134, and 138 are shown 

as a PCI bus slot, a PC Card slot, or an ISA, EISA or 50 external to computer 102 for illustrative purposes. In typical 

MicroChannel bus slot provided by the computer 102. industrial automation systems a device will not be present of 

However, these cards 122, 134, 138 and 114 are shown each interface type, and in fact many systems may only have 

external to computer 102 for illustrative purposes. one or more devices of a single interface type, such as only 

The VXI chassis or instrument 116 is coupled to the PLCs. The devices are coupled to the device or process 150. 

computer 102 via a VXI bus, MXI bus, or other serial or 55 Referring again to FIGS. 1 and 1A, the computer system 

parallel bus provided by the computer 102. The computer 102 preferably includes a memory media on which computer 

102 preferably includes VXI interface logic, such as a VXI, programs according to the present invention are stored. The 

MXI or GPIB interface card (not shown), which interfaces term "memory media" is intended to include an installation 

to the VXI chassis 116. The PXI chassis or instrument is media, e.g., a CD-ROM, or floppy disks 104, a computer 

preferably coupled to the computer 102 through the com- 60 system memory such as DRAM, SRAM, EDO RAM, etc., 

puter's PCI bus. or a non-volatile memory such as a magnetic media, e.g., a 

A serial instrument (not shown) may also be coupled to hard drive, or optical storage. The memory media preferably 

the computer 102 through a serial port, such as an RS-232 stores a graphical programming development system for 

port, USB (Universal Serial bus) or IEEE 1394 or 1394.2 developing and executing graphical programs. The graphical 

bus, provided by the computer 102. In typical instrumenta- 65 programs are operable to access capabilities or functionality 

tion control systems an instrument will not be present of of an object, such as an object exported by a server. The host 

each interface type, and in fact many systems may only have CPU executing code and data from the memory thus com- 
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prises a means for creating and executing graphical pro- 
grams according to the methods described below. 

The instruments or devices in FIGS. 1 and 1A are con- 
trolled by graphical software programs. Graphical software 
programs which perform data acquisition, analysis and/or 
presentation, e.g., for instrumentation control or industrial 
automation, are referred to as virtual instruments. 

In the preferred embodiment, the present invention uti- 
lizes the Lab VIEW or Bridge VIEW graphical programming 
systems, hereafter collectively referred to as LabVIEW, 
available from National Instruments. Also, in the preferred 
embodiment, the term "LabVIEW" is intended to include 
graphical programming systems which include G program- 
ming functionality, i.e., which include at least a portion of 
LabVIEW graphical programming functionality, including 
the BridgeVIEW graphical programming system. 

Also, the term "graphical programming system" is 
intended to include any of various types of systems which 
are used to develop or create graphical code or graphical 
programs, including LabVIEW and BridgeVIEW from 
National Instruments, Visual Designer from Intelligent 
Instrumentation, Hewlett-Packard's VEE (Visual Engineer- 
ing Environment), Snap-Master by HEM Data Corporation, 
DASYLab by DasyTec, GFS DiaDem, and GEDAE, among 
others. 

Although in the preferred embodiment the graphical pro- 
gramming system is involved with data acquisition/ 
generation, analysis, and/or display, and for controlling or 
modeling instrumentation or industrial automation 
hardware, it is noted that the present invention can be used 
for a plethora of applications and are not limited to instru- 
mentation or industrial automation applications. In other 
words, FIGS, 1 and 1A are exemplary only, and the present 
invention may be used in any of various types of systems. 
Thus, the system and method of the present invention is 
operable for creating graphical programs or graphical code 
for any of various types of applications, including general 
purpose software applications such as word processing, 
spreadsheets, network control, games, etc. 
FIG. 2 — Computer Block Diagram 

FIG. 2 is a representative block diagram of the host 
computer 102 (of FIG. 1). It is noted that the block diagram 
of FIG. 2 is representative only, and the computer 102 may 
have any of various architectures. Also, the elements of a 
computer not necessary to understand the operation of the 
present invention have been omitted for simplicity. 

The computer 102 includes at least one central processing 
unit or CPU 200 which is coupled to a processor or host bus 
202. The CPU 200 may be any of various types, including 
an x86 processor, a PowerPC processor, a CPU from the 
Motorola family of processors, a CPU from the SPARC 
family of RISC processors, as well as others. Main memory 
206 is coupled to the host bus 202 by means of memory 
controller 204, The main memory 206 stores a graphical 
programming system. The main memory 206 also stores 
operating system software as well as other software for 
operation of the computer system, as well known to those 
skilled in the art. The instrumentation control software will 
be discussed in more detail below. 

The host bus 202 is coupled to an expansion or input/ 
output bus 210 by means of a bus controller 208 or bus 
bridge logic. The expansion bus 210 is preferably the PCI 
(Peripheral Component Interconnect) expansion bus, 
although other bus types can be used. The expansion bus 210 
includes slots for various devices such as the data acquisi- 
tion board 114 (of FIG. 1), a GPIB interface card 122 which 
provides a GPIB bus interface for coupling to the GPIB 
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instrument 112 (of FIG. 1), and a VXI or MXI bus card 186 
for coupling to the VXI chassis 116 for receiving VXI 
instruments. 

The computer 102 further preferably comprises a video 

5 display subsystem 220 which interfaces to video monitor 
222, and a non-volatile memory such as hard drive 224, each 
preferably coupled to the expansion bus 210. The computer 
102 further preferably comprises various input devices, such 
as mouse 230 and keyboard 232, as shown. The input 

10 devices are shown coupled to the expansion bus 210, but 
may be connected to the computer in any of various ways, 
such as a USB port (not shown). The computer 102 further 
preferably comprises various other standard components, as 
is well known in the art. 

15 Graphical Programming System 

As noted above, in the preferred embodiment the present 
invention utilizes the LabVIEW or BridgeVIEW graphical 
programming system. A graphical program created using 
LabVIEW comprises an instrument front panel in a first 

20 window and a block diagram in a second window. The block 
diagram comprises program execution elements, referred to 
as nodes, which are wired or linked together to produce a 
data flow program. The front panel comprises controls for 
providing input data to the block diagram and indicators for 

25 receiving and/or displaying output data from the nodes of 
the block diagram. Certain drawings in the present disclo- 
sure comprise screen shots displayed during the execution of 
Lab VIEW according to the present invention. 
Graphical Programming Environment 

30 Referring now to FIG. 3, a block diagram illustrating the 
relationship of portions of the instrumentation control sys- 
tems 100 or 160 (of FIGS. 1 and 1A) are shown. Preferably, 
the elements shown in FIG. 3 (with the exception of the 
hardware instrument 254) are software elements which are 

35 executed on the computer 102 (of FIGS. 1 and 1A). The 
present invention is used to create a graphical program 
which is operable to access capabilities of one or more 
objects during execution. The present invention is also 
useable to create a graphical program portion which is a part 

40 of a larger graphical program. 

The present invention may be used to create a graphical 
program which is able to access capabilities of various types 
of objects, including software objects according to the 
standard notion of object oriented software, such as Java 

45 objects, C++ objects, etc.; software components, such as 
ActiveX controls; other types of re-usable software ele- 
ments; and applications; as well as other types of software 
constructs which offer capabilities or functionality. 
In the preferred embodiment, a programmer employs a 

50 front panel editor 262, a block diagram editor 264, and 
optionally a connector pane/icon editor 272 of a graphical 
programming environment to produce the graphical pro- 
gram. In the instrumentation application of the preferred 
embodiment, the graphical program is referred to as a virtual 

55 instrument (VI) 250. The block diagram editor 264 generates 
executable instructions, i.e., machine language instructions, 
in response to the VI 250. The VI 250 developed by the 
programmer is executed by an execution subsystem 256 of 
the graphical programming environment to control an instru- 

60 ment 254. The instrument 254 is illustrative of instruments 
such as those of FIGS. 1 and 1A. 

FIG. 6 is a screen shot from a graphical programming 
environment including a virtual instrument or graphical 
program exemplary of the VI 250 of FIG. 3 according to one 

65 embodiment. The screen shot of El G. 6 comprises an instru- 
ment front panel in a window in the upper portion of the 
screen and a block diagram in a window in the lower portion 
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of the screen. The block diagram comprises program execu- 
tion elements, referred to as nodes, which are wired or linked 
together to produce a data flow program. The front panel 
comprises controls for providing input data to the block 
diagram and indicators for receiving and/or displaying out- 
put data from the nodes of the block diagram. 

Preferably the graphical programming system comprises 
portions of National Instruments Lab VIEW software. The 
drawings of the present disclosure include numerous screen 
shots displayed during the execution of Lab VIEW. In the 
screen shots, Lab VIEW is executing under the supervision 
of the Microsoft Windows 95 operating system. For more 
information on the Lab VIEW graphical programming envi- 
ronment of the preferred embodiment, please see U.S. Pat. 
No. 5,481,741 referenced above. 

Referring again to FIG. 3, the graphical programming 
environment further comprises one or more object controls 
274. The front panel editor 262 is preferably operable to 
generate a VI front panel or user interface. The front panel 
editor 262 communicates with the controls) 274. More 
specifically, the user arranges on the screen one or more user 
interface items, referred to as controls and indicators, 
optionally including one or more of the object controls 274. 
Alternatively, the front panel or user interface is created 
automatically in response to creation of the block diagram, 
and the front panel editor 262 is not included. The controls) 
274 communicates with an object manager 268 to obtain or 
provide information regarding class/type libraries 270 in the 
system and object classes in the object type libraries 270. In 
one embodiment, the object controls operate as object nodes 
to reference an object and display changes made to the 
object. 

The graphical programming environment further com- 
prises object nodes 266, also referred to as object function 
nodes. Examples of object nodes 266 according to one 
embodiment are shown in the object nodes palette of FIG. 7. 
The object nodes 266 preferably include an object refnum, 
an object open node, an object close node, an object invoke 
node, an object property node, and a call node, among 
others. The block diagram editor 264 is operable to create a 
VI block diagram, or block diagram. The block diagram 
editor 264 communicates with the object nodes 266, which 
in turn communicate with the object manager 268. More 
specifically, the user arranges on the screen a plurality of 
nodes on the screen, including one or more object function 
nodes 266, to create a block diagram or graphical program. 

The object manager 268 accesses object class/type librar- 
ies 270 to acquire information necessary to perform object 
management operations. Preferably, the object manager 268 
communicates with the Windows operating system Registry, 
or other similar data structures, to obtain information regard- 
ing the object class/type libraries 270 in the system. The 
object control 274, object nodes 266, and object manager 
268 will be discussed in more detail below. 

Advantageously, the graphical programming 
environment, and in particular the object control 274, the 
object nodes 266, the object manager 268, and the object 
manager run- time library 258, enable a graphical program to 
instantiate objects of an unlimited number of object classes 
of object applications, and to remotely invoke properties and 
methods of the instantiated objects. 

The graphical programming environment further prefer- 
ably includes a connector pane/icon editor 272 for forming 
VFs into sub VFs, i.e., a VI which may be used as a 
graphical programming element in another VI. The reader is 
referred to U.S. Pat. No. 5,301,336 for more information 
about the sub VFs and the icon editor 272. 
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The execution subsystem 256 executes the executable 
instructions constructed from a block diagram of the VI 250. 
For more information about the execution subsystem 256 the 
reader is referred to U.S. Pat. No. 5,481,741. 

Preferably, the VI 250 invokes methods and properties of 
objects of an object server 252, or more than one object 
server, indirectly through the services of the object manager 
run-time library 258. Examples of the object server 252 
include Microsoft Excel, Access, Word, and National Instru- 
ments ComponentWorks controls. Other examples of the 
object server 252 include Claris Works. The VI 250 controls 
the instrument 254 through an instrument device driver 253 
which includes executable functions which are called by the 
VI 250 to perform operations in order to control the instru- 
ment 254. 

The object nodes 266 and object controls) 274 preferably 
comprise classes and objects^ according to the notion of 
classes and objects in the art of object-oriented program- 
ming. Each of the object nodes 266 and the object controls 
274 comprise their own properties and methods. The meth- 
ods include a method for drawing an icon representation of 
the object on the video display 145 of the computer 102 
either in the VI block diagram or front panel, a method for 
generating code associated with the different functions of 
each node or control, and a method for performing type 
propagation checking. The operation of object nodes 266 
and object control 274 will be explained in more detail 
below. As mentioned above, the object nodes 266 comprise 
an object refnum associated with the object control 274, an 
object open node, an object property node, an object invoke 
node, and an object close node. 

FIG. 3a illustrates an alternate embodiment of the system 
100 of FIG. 3. This embodiment is similar to that shown in 
FIG. 3 and corresponding elements are numbered identi- 
cally. In the embodiment of FIG. 3a the object server 252 is 
a program capable of controlling an instrument 254. In other 
words, in FIG. 3 the graphical program client directly 
controls the instrument 254, and the client uses the object 
server to aid in controlling the instrument 254. In FIG. 3a, 
the object or object server directly controls the instrument 
254. For example, the object server 252 may be a program 
written in the C language for controlling a GPIB instrument. 
The client VI 250 instantiates objects from the classes 
exported by the object server 252 and invokes methods and 
properties of the objects to direct the object server 252 to 
control the instrument hardware 254, 

As mentioned above, the graphical program 250 is not 
necessarily related to controlling an instrument, but rather 
the graphical program 250 may be for any of various 
applications. That is, the object client may have an appli- 
cation other than instrumentation control. In one embodi- 
ment similar to that of FIG. 3a } the VI 250 is an object client 
application which performs other functions. For example, a 
programmer desires to develop a stock portfolio viewer in a 
graphical programming environment and develops an object 
client to access Microsoft Excel spreadsheet objects in order 
to display a stock portfolio. 

Advantageously, the graphical system and method for 
producing the graphical program or VI 250 has a number of 
benefits. These benefits include reduction in the develop- 
ment time required to create the VI 250 as well as reduction 
of the number of code defects in the VI 250. Yet another 
benefit is the simplicity of programming which makes the 
development of a graphical program, such as an instrumen- 
tation control program, more practical for a larger number of 
people, i.e., those who might not have the skills, or resources 
to develop the skills, to develop programs according to more 
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conventional text-based methods. The system and method ping up" on the object node and using a dialog box or menu 

also provides class propagation, class checking and type to select the desired methods and/or properties. Thus, the 

checking in a graphical programming environment, dis- user preferably configures the object node for the desired 

cussed further below, thus simplifying program develop- functionality. 

ment. 5 Creation of the graphical program may also include 
FIGS. 4 and 5 — Creation and Execution of a Graphical configuring a user interface to display data input to and/or 
Program Including Object Nodes output from the graphical program. In one embodiment, 
FIG. 4 is a flowchart diagram illustrating creation of a such as the Lab VIEW graphical programming system from 
graphical program including an object node according to the National Instruments, the user may separately configure or 
present invention. As shown, during creation of the graphi- 10 assemble a user interface panel including user interface 
cal program, in step 302 the user operates to place an object nodes, such as dials, switches, charts, graphs, etc. In this 
node in the graphical program, wherein the object node is embodiment, terminals which correspond to each of the user 
operable to access capabilities of the object. Stated another interface nodes appear in the block diagram and operate to 
way, during program creation the computer system displays provide or represent data input to/output from the block 
on the screen an object node in the graphical program in 15 diagram. In another embodiment, the user assembles user 
response to user input, wherein the object node is operable interface nodes into the block diagram with the function 
to access capabilities of the object. In the preferred nodes, wherein the user interface nodes have associated user 
embodiment, the user drags the' object node from a palette interface elements, such as dials, sliders, text boxes, graphs, 
onto the graphical program window. charts, etc. The user may then selectively view the user 
In step 304 the user arranges on the screen the graphical 20 interface elements associated with each of the user interface 
program, including the object node. The graphical program nodes, such as in Hewlett Packard's VEE product, 
will typically comprise a plurality of nodes, and the method Alternatively, the user interface panel is automatically con- 
fer creating the graphical program preferably comprises structed from the user interface nodes in the block diagram, 
arranging on the screen the plurality of nodes, including the such as in the Visual Designer product from Intelligent 
object node, and connecting the various nodes to create the 25 Instrumentation. 

graphical program. In the preferred embodiment, the nodes Once the graphical program has been created, then during 

are connected in a data flow paradigm, wherein nodes execution of the graphical program, the object node is 

include inputs and outputs, and each node receives input operable to access the capabilities of the object. More 

data from another node, or from an input user interface node specifically, after creation of the graphical program, execu- 

or terminal, and each node provides output data to another 30 tion of the graphical program operates as shown in FIG. 5. 

node, or to an output user interface node or terminal. FIG. 5 is a flowchart diagram illustrating execution of the 

In step 306 the user then configures the object node to graphical program created in FIG. 4, wherein the object 

receive information on the object, preferably by the user node operates to access capabilities of an object according to 

configuring the object node with a reference to the object, the present invention. As shown, in step 312 the system/ 

e.g., a pointer, address, or other information which specifies 35 method constructs execution instructions in response to the 

the identity and/or location of the object. Step 306 is graphical program, wherein the execution instructions are 

preferably performed as part of arranging the graphical executable to access the capabilities of the object. In step 

program on the screen in step 304. 314 the execution instructions are executed. When these 

In the preferred embodiment, the object node includes an execution instructions are executed, the object node accesses 
object reference input for receiving a reference to the object, 40 the capabilities of the object, such as invoking method(s) of 
and the user connects the object reference input of the object the object and/or getting/setting properties of the object, 
node to receive the reference to the object. This preferably In the preferred embodiment, the object may be any of 
includes the user placing an object reference node in the various types of software, such as a software object accord- 
graphical program, wherein the object reference node ing to the standard principles of object-oriented software, a 
includes an object reference output that provides the refer- 45 software component, other types of re-usable software 
ence to the object, and the user connecting the object elements, or an application, among others. Where the object 
reference output of the object reference node to the object is a software object or component, the object node is 
reference input of the object node. The object node then executable to either invoke a method of the object, get 
receives the information on the object on the object refer- and/or set one or more properties of the object, or access 
ence input during execution of the graphical program. 50 other capabilities of the object. Where the object is an 

Alternatively, the user "pops up" on the object node to application, the object node is operable to perform one or 

configure the object node with the reference to the object. more of 1) initiate execution of the application; or 2) get/set 

When the user "pops up" on the object node, a dialog box one or more properties of the application. Also, the object 

appears. The user then enters information into the dialog box may reside in the same computer where the graphical 

to configure the object node with the reference to the object. 55 program is being created, or may reside in a different 

Step 306 also preferably includes the user selecting the computer connected through a network, 

class of the object. Once the class is selected, then the object In the preferred embodiment, the graphical program com- 

is preferably instantiated at run time. Step 306 further prises a diagram or execution portion and a user interface 

includes selecting any desired methods to be invoked on the portion, and the object node is comprised in the diagram 

object or properties to get/set on the object. For example, if 60 portion. Alternatively, the object node may be comprised in 

the object node is an invoke node, the user preferably selects the user interface portion. In this case where the object node 

one or more methods which are to be invoked on the object is located in the user interface, the object is preferably 

by the invoke node during execution of the graphical pro- comprised in the object node, and the object node operates 

gram. If the object node is a property node, the user to manipulate the object. For example, the document com- 

preferably selects one or more properties to get/set on the 65 prised in the object node, wherein the object node is oper- 

object during execution of the graphical program. The user able to display object may be a changes to the document 

preferably selects the methods and/or properties by "pop- during execution of the graphical program. As another 
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example, the object may be a user interface element, such as 
a control or indicator, wherein the object node is operable to 
affect the data input to or output from the control or indicator 

EMBODIMENTS OF THE INVENTION 5 

The following comprise various embodiments of the 
present invention. FIGS. 8-36 illustrate one embodiment of 
the present invention used for creating a graphical program, 
wherein the graphical program is executable to access 10 
capabilities of one or more objects. FIGS. 37-50 illustrate a 
specific embodiment of FIGS. 8-36, where the object whose 
capabilities are being accessed is an application, such as a 
graphical program application, e.g., Lab VIEW. FIGS. 51-55 
illustrate an embodiment where the object node is a user 15 
interface element, such as an ActiveX container, which 
manipulates data on objects comprised in the node. 

FIGS. 8-36: First Embodiment 
Graphical Program Client Creation 20 

FIG. 8 is a flowchart illustrating steps taken to create a 
graphical program, referred to as a graphical program client 
or graphical automation client, according to the preferred 
embodiment of the method. The flowchart of FIG. 8 pro- 
vides a high level view of the method of the preferred 25 
embodiment. The flowchart of FIGS. Ha-Hc provide a more 
detailed view of the method of this embodiment. Thus the 
flowchart of FIG. 8 provides a high level view of the steps 
of the flowchart of FIGS. Ha, Hb, and 8c, and corresponding 
steps are numbered identically. The screen shot of FIG. 6 30 
illustrates an example graphical program created according 
to the flowchart of FIG. 8. The nodes illustrated in FIG. 7 are 
example object nodes, referred to as automation function 
nodes, which are used in the flowchart of FIG. 8. In this 
description, the terms "automation" and "object" are used 35 
substantially interchangeably. 

As shown in FIG. 8, the user drops or places an automa- 
tion control icon on a virtual instrument front panel, and in 
response the block diagram editor 264 displays a corre- 
sponding automation class refnum icon in the block 40 
diagram, in steo 380. The user then selects an automation 
class to associate with the automation refnum. The automa- 
tion refnum receives the user input and associates the 
user-selected automation class with the automation refnum, 
in step 392. 45 

The user drops an automation open node on the block 
diagram and in response the block diagram editor 264 
displays an automation open node icon, in step 394. The user 
connects the automation refnum and the automation open 
node and in response the block diagram editor 264 displays 50 
a wire connecting the automation refnum and the automation 
open node, in step 396. 

The user drops an automation function node in the block 
diagram and in response the block diagram editor 264 
displays an automation function node, in step 398. An 55 
automation function node preferably comprises an automa- 
tion property node or an automation invoke node. In one 
embodiment, an automation function node may perform 
functions or access capabilities of automation objects other 
than invoking methods and properties, such as event 60 
handling, i.e., the automation function node may be an 
automation event node. The user connects the automation 
open node and the automation function node and in response 
the block diagram editor 264 displays a wire connecting the 
automation open node and the automation function node, in 65 
step 400. The user may drop both an automation invoke node 
and an automation property node in creating the graphical 
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automation client. Furthermore, the user may drop one or 
more of both automation property nodes and automation 
invoke nodes in order to invoke multiple properties and/or 
methods in creating the graphical automation client. 
Alternatively, a single invoke node may be configured to 
invoke multiple methods and a single property node may be 
configured to get/set multiple properties. 

The user then selects a property or method and in response 
the automation property node or automation invoke node 
receives the user input and associates the user-selected 
property or method, respectively, with the automation prop- 
erty node or automation invoke node, respectively, in step 
406. 

The graphical programming environment then constructs 
execution instructions based on the graphical program com- 
prising the automation refnum, automation open node, auto- 
mation property node and/or automation invoke node, and 
wires, in step 426. The graphical programming environment 
then executes the execution instructions, in step 428. A more 
detailed description of the steps of FIG. 8 is given below 
with regard to FIGS. Ha, Hb, and 8c. 

In the embodiment of FIG. 8, the user selects the object 
class in steps 382 and 392 utilizing an automation class 
refnum, and in steps 394 and 396 an automation open node 
is placed in the block diagram, which operates to instantiate 
an object of the selected class. In one embodiment, a single 
re mum or node is used to both select the object class and 
instantiate the object. Alternatively, selection of the class 
and instantiation of the object are performed when the object 
node is displayed in step 398. In this latter embodiment, 
when the user selects the object node or automation function 
node for inclusion in the graphical program, at that time the 
user selects the desired class and then selects the methods 
and/or properties. An object from this selected class is then 
instantiated by the object node at run-time. 

FIGS. 8a, Hb, and 8c are a more detailed flowchart 
illustrating steps taken to create a graphical automation 
client according to the preferred embodiment of the method. 
The flowchart of FIGS. Ha-Hc illustrates an embodiment 
which presumes the use of an automation close refnum and 
an open node to select the class and instantiate the object, 
respectively. A user drags, preferably using a mouse, an 
automation control from a refnum palette, shown in FIG. 9, 
and drops the automation control on a VI front panel. 

In response to the user dropping the automation refnum, 
the front panel editor 262 displays an automation control in 
the front panel, and the block diagram editor 264 displays an 
automation refnum associated with the automation control in 
a block diagram in step 380. Alternatively, the user drops an 
automation refnum from the palette of FIG. 7 and the front 
panel editor 262 invokes a method of the automation control 
274 to draw an automation control icon in the front panel. 

Preferably, the automation control 274 comprises a draw 
method which the front panel editor 262 and block diagram 
editor 264 invoke in order to display an automation control 
icon in the front panel and to display an automation refnum 
icon in the block diagram, respectively. FIG. 8 shows an 
automation refnum displayed in a block diagram. FIG. 8 also 
shows a pop-up menu for the automation refnum including 
a "Select OLE Class" menu item with a "Browse" item. 
Preferably, the user right clicks a mouse on the automation 
refnum in order to see the pop -up menu. 

In one embodiment, an automation client program, i.e., a 
VI, developed using the graphical programming environ- 
ment is capable of invoking methods of and modifies 
attributes of objects via a plurality of automation 
technologies, including Microsoft Automation. Examples of 
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other automation technologies are OpenDoc and the Com- 
mon Object Request Broker Architecture (CORBA). In this 
embodiment, the object manager 68 obtains a list of auto- 
mation technologies in the system. The automation refnum 
queries the object manager 268 for the list and displays the 
list of automation technologies for the user in step 382. The 
user selects one of the automation technologies from the 
displayed list of automation technologies. In response to the 
user selection, the automation refnum selects the automation 
technology from the list of automation technologies and 
associates the selected automation technology with the auto- 
mation refnum in step 384. 

The automation refnum is a reference to a user-selected 
automation class. The automation refnum includes a refnum 
output terminal, to which a wire may be connected. At 
edit-time, the automation refnum provides, at its output 
terminal, a type descriptor which specifies an automation 
class and the type library to which the automation class 
belongs. The type library is one of the type libraries 270 of 
FIG. 3. Type descriptors will be described in detail below. 
The time during which a user is creating, i.e., editing a VI 
50, by dropping nodes and wiring them together, is referred 
to as "edit-time." The time when instructions of the VI 50 
are executed is referred to as "run-time". 

Referring again to FIG. Ha, in response to user input, the 
automation refnum queries the object manager 268 for a list 
of type libraries 270 (of FIG. 3) associated with the auto- 
mation servers present in the system. The automation 
refnum displays the list of type libraries 270 associated with 
the automation servers in step 386. Preferably, the object 
manager 268 provides the automation refnum with a list of 
OLE Automation type libraries in the system. In one 
embodiment, the object manager 268 provides the automa- 
tion refnum with a list of type libraries for each automation 
technology in the system. 

Preferably, the user input includes the user clicking on the 
"Browse" item of the "Select OLE class" item of the 
automation refnum pop-up menu, shown in FIG. 12, and 
selecting the pull -down menu in the "Type Library" window 
shown in FIG. 12. Preferably, the object manager 268 
queries the Windows Registry to obtain a list of OLE 
Automation type libraries present in the system. Preferably, 
the automation refnum displays the type libraries associated 
with the OLE Automation servers present in the system, as 
shown in FIG. 11. In one embodiment, the automation 
refnum displays the type libraries associated with the auto- 
mation technology which was selected in step 384. 

The user selects one of the type libraries from the dis- 
played list of type libraries. In response, the automation 
refnum selects the type library from the list of type libraries 
and associates the selected type library with the automation 
refnum in step 388. At edit-time the automation refnum 
provides a type descriptor, including information identifying 
the selected type library, to other automation nodes of the VI 
50. FIG. 12 shows the user having selected the "Microsoft 
Excel 5.0 Object Library Version 1.0" type library from the 
list of FIG. 11. 

In response to the user having selected a type library, the 
automation refnum queries the object manager 268 for a list 
of possible automation classes associated with the selected 
type library in step 390. The object manager 268 queries the 
selected type library for a list of possible automation classes 
in the type library. The object manager 268 receives tbe list 
of automation classes from the type library and provides the 
list to the automation refnum. The automation refnum 
receives the list from the object manager 68 and displays the 
list, as shown in FIG. 12. FIG. 12 shows the list of possible 
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Microsoft Excel 5.0 automation classes from which auto- 
mation objects may be instantiated. Preferably, the user may 
choose for the automation refnum to selectively display only 
those objects which are creatable, as shown in FIG. 12. 

5 The user selects an automation class from the displayed 
list of automation classes. In response, the automation 
refnum selects the automation class from the list of auto- 
mation classes and associates the selected automation class 
with the automation refnum in step 392. At edit-time the 

10 automation refnum provides a type descriptor, including 
information identifying the selected automation class, to 
other automation nodes of the VI 50. FIG. 13 shows the user 
having selected the "Excel Application" automation class 
from the list of FIG. 12. Thus, the system and method 

15 displays an automation refnum icon which is used to indi- 
cate an input type library and automation class. 

Below an automation open node is described in detail. In 
one embodiment, the system and method displays the auto- 
mation open node icon which is used to indicate the type 

20 library and automation class information input from a user, 
rather than the automation refnum. That is, the automation 
open node serves the function of the automation refnum by 
receiving the type library and automation class information 
from the user and displaying the selected information. 

25 Type Descriptor 

Each wire and terminal in a block diagram has an asso- 
ciated data type. The programming environment keeps track 
of the data type in a structure in memory called a type 
descriptor. The type descriptor comprises a string of word 

30 integers that describe the data type. The generic format of a 
type descriptor is: 
<size> <typecode>. 

Table 1 lists three of the supported data types, the type 
codes, and type descriptors in one embodiment of the 
35 programming environment. 



TABLE 1 



40 



Data Type 


Type Code 


Type Descriptor 


Long Integer 


0x03 


0004 xx03 


Handle 


0x31 


0006 xx 31 <kind> 


Array 


0x40 


<nn> 0x40 <k> <k dimensions > 






<element type descriptors 



45 When a wire is initially connected to a terminal, the wire 
takes on the data type of the terminal, i.e., the programming 
environment creates a type descriptor for the wire. When the 
user connects this wire to another terminal in the block 
diagram at edit-time, the programming environment per- 

50 forms type propagation checking by comparing the type 
descriptor of the wire with the type descriptor of the termi- 
nal. If the type descriptors do not match, then a type conflict 
error is generated. In one embodiment, the programming 
environment performs type propagation checking on each 

55 wire and terminal in the block diagram each time a change 
is made to the diagram. That is, type descriptors are propa- 
gated on the wires of the block diagram at edit-time in order 
to perform type propagation checking. 
The method advantageously comprises a new type 

60 descriptor for the automation refnum terminal. The automa- 
tion refnum terminal type descriptor includes an identifier 
for the automation class associated with the automation 
re mum and an identifier for the type library for the auto- 
mation class. In one embodiment, the automation refnum 

65 type descriptor has the format: 

<size> <RefnumCode> <AutoRefnumKind> <Automa- 
tionType> <no of int!6 , s> <kCoClassCLSID> <CLSID of 



02/17/2004, EAST Version: 1.4.1 



us 6,4: 

21 

created object> <kTypeLibCLSID> <CLSID of type 
library> <DISPID>. 

The <size> byte of the type descriptor is as described above. 
The <refnumCode> is the type code for a refnum. The 
<AutoRefnumKind> value distinguishes this refnum from 
other refmims as an automation refnum. The <Automation- 
Type> indicates the OLE automation type, such as the 
<kStOLEAutoType> value which indicates a static OLE 
automation type. The <no of intl6*s> field indicates the 
number of 16 bit words which follow. The <kCo Class - 
CLSID> value indicates the following 128 bits are a class 
identifier. The <CLSID of created object> is a unique 128 bit 
number associated with the particular automation class 
which the automation refnum references. The <kTypeLib- 
CLSID> value indicates the following 128 bits are a type 
library identifier. The <CLSID of type library> is a unique 
128 bit number associated with the particular type library to 
which the automation class belongs. The <DISPID> is a 
Dispatch ID, which is a long integer which uniquely speci- 
fies a class within a type library. The Dispatch ID is 
associated with the Microsoft IDispatch interface for dis- 
patch methods and properties. The Dispatch ID is unique 
within a type library. In the example shown in FIG. 11, the 
type descriptor provided by the automation refnum includes 
information to specify the Microsoft "Excel" automation 
application type library and the "Application" automation 
class. 

The automation nodes comprise a type propagation 
checking method which may be invoked by the block 
diagram editor 64 to perform type propagation checking. 
When the user connects a wire to a terminal of an automa- 
tion node, the type propagation method of the node is 
invoked and the type descriptor of the wire being connected 
to the terminal is passed as an argument to the type propa- 
gation method. This information in the type descriptor 
enables the type propagation method to advantageously 
determine class conflicts in the block diagram. 

Thus, the method advantageously performs type propa- 
gation checking to determine program correctness when 
wiring automation function nodes. This checking advanta- 
geously prevents run-time errors which would occur when 
the user attempted to invoke a method or property which is 
invalid for the automation class selected. Type propagation 
checking is discussed further below. 

The user creates an automation open node for instantiat- 
ing an object from the automation class referred to by the 
automation refnum. Preferably, the user drags an automation 
open node from the automation nodes palette of FIG. 7 and 
drops the automation open node on the block diagram. 

In response to the user dropping the automation open 
node on the block diagram, the block diagram editor 264 
displays an automation open node in the block diagram, as 
shown in FIG. 13, in step 394. Preferably, the block diagram 
editor 264 invokes a draw method of the automation open 
node to display an automation open node icon in the block 
diagram. At run-time, the automation open node instantiates 
an object based on the automation class and type library 
information received from the automation refnum. 

The system then connects the automation refnum to the 
automation open node in response to user input. The user 
wires the automation open node to the automation refnum 
using a wiring tool. In response, the block diagram editor 
264 displays a wire connecting the automation open node 
and the automation refnum in step 396. The automation 
refnum provides the automation class and type library 
information to the automation open node so that the auto- 
mation open node may perform type propagation checking. 
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The automation open node includes a refnum input ter- 
minal which is designed to receive an output from an 
automation refnum icon. In an embodiment where an auto- 
mation refnum icon is not used to designate class and type 

5 library information, the automation open node receives the 
class and type library information by other means, prefer- 
ably via user input in a similar manner which the automation 
refnum received the class and type library information. At 
edit- time, the automation open node receives a type descrip- 
tor on the wire, such as from the automation refnum, which 
includes type library and automation class information. The 
automation open node also includes a refnum output 
terminal, to which a wire may be connected. At edit-time, 
the automation open node forwards the type descriptor 
received at its refnum input terminal to the refnum output 

15 terminal. The type descriptor is forwarded on a connected 
wire to all other nodes connected to the wire. 

At run-time, the automation open node provides a refer- 
ence to the object instantiated by the automation open node 
on the wire connected to the refnum output terminal. Auto- 

20 mation nodes, such as automation invoke nodes and auto- 
mation property nodes, receive the object reference in order 
to invoke methods and properties of the object as will be 
described below. 
The user creates an automation property node in order to 

25 invoke properties, i.e., to set or get properties, of the object 
instantiated by the automation open node. Preferably, the 
user drags an automation property node from the automation 
nodes palette of FIG. 7 and drops the automation property 
node on the block diagram, as shown in FIG. 16. The user 

30 may also create an automation property node via the pop-up 
menu of the automation open node. 

In response to the user dropping the automation property 
node, the block diagram editor 264 invokes a method on the 
automation property node to display an automation property 

35 node icon in the block diagram in step 398a. The automation 
property node is used to invoke properties of the object. The 
properties to be invoked by the automation property node 
are selected by the user creating the VI 50. 
The user wires the automation property node to the 

40 automation open node using a wiring tool. The automation 
property node includes a refnum input terminal through 
which the automation property node receives an object 
reference and type descriptor. In response to the user wiring 
the automation property node and the automation open node, 

45 the block diagram editor 64 displays a wire connecting the 
refnum input terminal of the automation property node and 
the refnum output terminal of the automation open node in 
step 400a. 

It is noted that the refnum input terminal of the automa- 

50 tion property node may instead be connected to other wires 
which provide the reference to the object and type descriptor 
rather than the automation open node refnum output termi- 
nal. For example, the refnum input terminal of the automa- 
tion property node may be connected to the refnum output 

55 terminal of another automation property node of the same 
object or to the refnum output terminal of an automation 
invoke node of the same object. 

At run-time, the automation property node receives a 
reference to the instantiated object via its refnum input 

60 terminal so that the automation property node may set or get 
properties of the instantiated object. 

At edit-time, the automation property node receives a type 
descriptor via its refnum input terminal so that the automa- 
tion property node may perform type propagation checking. 

65 The automation property node also uses the information in 
the type descriptor at edit-time to perform other operations, 
such as displaying property lists as described below. 
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The automation property node also includes a refnum 
output terminal. The automation property node passes the 
information received on its refnum input terminal to its 
refnum output terminal, i.e., the type descriptor, at edit-time 
and the object reference at run -time. 

Preferably, the user selects the "Properties" menu item 
from the automation property node pop -up menu in order to 
view a list of properties associated with the automation 
class, as shown in FIG. 14. In response to the user selecting 
the Properties item, the automation open node (or other 
automation node) provides information on the selected auto- 
mation class and selected type library to the automation 
property node in step 102. Preferably, providing information 
on the automation class and selected type library includes 
providing a type descriptor which includes the information. 

Using the automation class and type library information, 
the automation property node queries the object manager 
268 for a list of properties associated with the selected 
automation class in step 403. In response, the object man- 
ager 268 queries the selected type library for a list of 20 
properties of the specified automation class in step 404. The 
object manager 68 receives the list of properties from the 
type library and provides the list to the automation property 
node. The automation property node uses the information 
received from the object manager 268 to display the list of 25 
properties of the selected automation class, as shown in FIG. 
14, in step 405. 

The user selects one of the properties in the displayed list 
of properties. In response to the user selection, the automa- 
tion property node selects the selected property to be 30 
invoked by the automation property node in step 406a. The 
automation property node displays the selected property in 
the automation property node, as shown in FIG. 15, in step 
408. FIG. 15 shows a "Visible" property displayed in the 
Excel Application automation property node. 

The automation property node displays a terminal for the 
selected property, as shown in FIG. 15, in step 410. If the 
property may be set, i.e., written, the automation property 
node displays an input terminal. If the property may be 
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methods to be invoked by the automation invoke node are 
selected by the user creating the VI 50. 

The user wires the automation invoke node to the auto- 
mation open node using a wiring tool. The automation 
invoke node includes a refnum input terminal through which 
the automation invoke node receives an object reference and 
type descriptor. In response to the user wiring the automa- 
tion invoke node and the automation open node, the block 
diagram editor 264 displays a wire connecting the refnum 
input terminal of the automation invoke node and the refnum 
output terminal of either the automation open node or an 
automation property node in step 4006. 

It is noted that the refnum input terminal may instead be 
connected to other wires which provide the reference to the 
object and type descriptor rather than the automation open 
node refnum output terminal. For example, the refnum input 
terminal of the automation invoke node may be connected to 
the refnum output terminal of another automation invoke 
node of the same object or to the refnum output terminal of 
an automation property node of the same object. 

At run-time, the automation invoke node receives a ref- 
erence to the instantiated object via its refnum input terminal 
so that the automation invoke node may invoke methods of 
the instantiated object. 

At edit-time, the automation invoke node receives a type 
descriptor via its refnum input terminal so that the automa- 
tion invoke node may perform type propagation checking. 
The automation invoke node also uses the information in the 
type descriptor at edit-time to perform other operations, such 
as displaying method lists as described below. 

The automation invoke node also includes a refnum 
output terminal. The automation invoke node passes the 
information received on its refnum input terminal to its 
refnum output terminal, i.e., the type descriptor, at edit-time 
and the object reference at run-time. 

Preferably, the user selects the "Methods" menu item 
from the automation invoke node pop -up menu in order to 
view a list of invoke associated with the automation class, as 
shown in FIG. 16. In response to the user selecting the 



gotten, i.e., read, the automation property node displays an 40 Methods item, the automation open node (or other automa- 



output terminal. Preferably, a property may be set to be 
readable or writable in response to user input. In FIG. 15, the 
Visible property includes an input terminal since the prop- 
erty may be set, i.e., changed. The Visible property input 
terminal receives a Boolean, i.e., True/False, input value 
which may be toggled on the front panel in response to user 
input. 

In a similar manner, the user is enabled to add more 
properties to the automation property node for the purpose 
of invoking the properties of the object. Typically, the 
properties are set via controls on the front panel associated 
with the block diagram or gotten and displayed on indicators 
on the front panel. In addition, the properties may be 
invoked programmatically using nodes and terminals of the 
VI 50. 

The user creates an automation invoke node in order to 
invoke methods of the object instantiated by the automation 
open node. Preferably, the user drags an automation invoke 
node from the automation nodes palette of FIG. 7 and drops 
the automation invoke node on the block diagram, as shown 
in FIG. 16. The user may also create an automation invoke 
node via the pop-up menu of the automation open node. 

In response to the user dropping the automation invoke 
node, the block diagram editor 64 invokes a method on the 
automation invoke node to display an automation invoke 
node icon in the block diagram in step 398b. The automation 
invoke node is used to invoke methods of the object. The 
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tion node) provides information on the selected automation 
class and selected type library to the automation invoke node 
in step 416. Preferably, providing information on the auto- 
mation class and selected type library includes providing a 
type descriptor which includes the information. 

Using the automation class and type library information, 
the automation invoke node queries the object manager 268 
for a list of methods associated with the selected automation 
class in step 417. In response, the object manager 268 
queries the selected type library for a list of methods of the 
specified automation class in step 418. The object manager 
68 receives the list of methods from the type library and 
provides the list to the automation invoke node. The auto- 
mation invoke node uses the information received from the 
object manager 268 to display the list of methods of the 
selected automation class, as shown in FIG. 16, in step 419, 

The user selects one of the methods in the displayed list 
of methods. In response to the user selection, the automation 
invoke node selects the selected method to be invoked by the 
automation invoke node in step 406b. The automation 
invoke node displays the selected method in the automation 
invoke node, as shown in FIG. 17, in step 422. FIG. 17 
shows a "Workbooks" method displayed in the Excel Appli- 
cation automation invoke node. 

The automation invoke node displays a terminal for each 
of the parameters of the selected method, as shown in FIG. 
17, in step 424. If the method includes input parameters, the 
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automation invoke node displays an input terminal for each 
input parameter. If the includes output parameters, the 
automation invoke node displays an output terminal for each 
of the output parameters. In FIG. 17, the Workbooks method 
includes an "Index" parameter. An input terminal and an 5 
output terminal are displayed for the Index parameter since 
it is both an input and output parameter. The Index input 
terminal receives an integer input value which may be 
specified on the front panel in response to user input. In 
addition, the Workbooks method returns an output 10 
parameter, and FIG. 17 displays an output terminal for the 
Workbooks method. 

FIG. 17 also shows an automation close node wired to the 
automation invoke node for freeing, i.e., deconstructing, the 
instantiated object at run-time referenced on the wire con- 15 
necting the automation invoke node refnum output terminal 
and the automation close node refnum input terminal. 

It is noted that the order in which an automation refnum, 
an automation open node, an automation property node, and 
an automation invoke node are dropped, wired, and config- 20 
ured is not fixed. For example, the automation open node 
could be dropped first. The automation open node includes 
a "Configure" item in its pop-up menu which automatically 
creates a configured automation control and associated auto- 
mation refnum, and wires the automation refnum output 25 
terminal to the automation open node refnum input terminal. 
In another example, an automation property node and an 
automation invoke node may be wired together in "parallel". 
That is, the automation refnum input terminal of each of an 
automation invoke node and an automation property node 30 
may be wired to the same wire emanating from the auto- 
mation refnum output terminal of an automation open node. 

Furthermore, a graphical automation client may be cre- 
ated with just an automation invoke node and no automation 
property node or a graphical automation client may be 35 
created with just an automation property node and no 
automation invoke node. That is, steps 298a through 410, 
and steps 426 and 428 could be performed without steps 
398fc through 424 being performed. Likewise, steps 3986 
through 428 could be performed without steps 398a through 40 
410 being performed. 

Once the user has created the VI 50, the user instructs the 
graphical programming environment to construct execution 
instructions in accordance with the nodes in the block 
diagram in step 426. Preferably, constructing the execution 45 
instructions comprises generating machine language instruc- 
tions into an executable program. Alternatively, constructing 
the execution instructions comprises generating program- 
ming language instructions, such as C language instructions, 
and compiling the programming language instructions into 50 
an executable program. In one embodiment, the user causes 
the execution instructions to be generated by clicking on the 
run button, indicated by a double wide right-pointing arrow 
at the far left of the toolbar of the front panel of FIG. 17. In 
addition, the user causes the execution instruction to be 55 
generated by saving the virtual instrument to a file via the 
File pull-down menu of FIG. 17. 

Constructing the execution instructions includes invoking 
code generation methods for each of the automation nodes. 
The automation open node generates instructions to iostan- 60 
tiate an object from the automation class indicated by the 
automation refnum. Preferably, the automation class and 
type library information is included in the execution instruc- 
tions generated by the automation open node. The automa- 
tion property node generates instructions for invoking the 65 
properties of the automation property node. The instructions 
set properties according to the values supplied at corre- 



,805 Bl 

26 

sponding property input terminals and get property values 
and provide the values to corresponding output terminals. 
The automation invoke node generates instructions for 
invoking the selected method of the automation invoke 
node. The instructions invoke the method with the values 
supplied at the parameter input terminals and supply return 
values at the output terminals. 

Once the execution instructions have been generated, the 
user directs the environment to execute the execution 
instructions. In response, the execution subsystem 256 (of 
FIG. 3) executes the execution instructions of the VI 50 in 
step 428. Preferably the user clicks the run button, or selects 
the run menu item from the Operate menu of FIG. 17, to 
execute the execution instructions. In one embodiment, the 
execution instructions are interpreted rather than compiled. 

Thus, the method enables a user to create an automation 
client application by means of a graphical programming 
environment to instantiate objects from automation classes 
and invoke methods and properties of the automation 
objects. 

Context-Sensitive Help Display 

FIG. 18 is a flowchart illustrating steps taken to display an 
application help screen for an automation object according 
to the preferred embodiment. A user creates a VI, such as the 
VI 50 of FIG. 3, according to the steps of the flowchart of 
FIG. 8. The VI includes an automation invoke node and/or 
an automation property node, referred to generically as an 
automation node. The block diagram editor 264 displays a 
method in an automation invoke node or a property in an 
automation property node, as shown in FIG. 19, in step 502. 
In particular, FIG. 19 shows a "Workbooks" method of 
"Application" automation class from the type library of an 
"Excel" automation server, i.e., an automation application. 

The user provides user input, preferably right-clicking 
with a mouse on the automation node, to view a pop -up 
menu. In response to the user input, the automation node 
displays an application help option for the method/property 
indicated by the user input, as shown in FIG. 20, in step 504. 
Preferably, displaying an application help option includes 
displaying a pop -up menu with a help item. In FIG. 20 the 
help item is the "Help for Workbooks" item. 

The user selects the help item, preferably by clicking on 
the help item with a mouse. In response to the user selection 
of the help item, the automation node requests help screen 
information for the method/property from the object man- 
ager 268 (of FIG. 3) in step 506. The automation node passes 
information specifying the method/property to the object 
manager 268. The object manager 268 returns the requested 
information. 

The automation node receives the requested information 
from the object manager 268 in step 508. Preferably, the 
requested information includes context for the method or 
object and a reference to a help file which includes the help 
screen to be displayed. In response to receiving the 
requested information, the automation node displays a help 
screen for the method/property, as shown in FIG. 21, in step 
510. FIG. 21 shows a help screen for the Excel Application 
Workbooks method. It is noted that the same steps apply for 
a property as for a method even though the steps have been 
illustrated via screen shots with reference to a method. 

Thus, the method provides a useful means for providing 
context sensitive help information for a user creating an 
automation client by means of the graphical programming 
environment. 

In one embodiment, automation classes and methods 
and/or properties of the classes are dynamically specified. 
Preferably, the classes and methods are specified via a front 
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panel control. The alternate embodiment is advantageous in 
circumstances wherein it is desired to access an automation 
server application which does not publish a type library. The 
type descriptor for the dynamically specified automation 
class and method and/or property embodiment includes an 5 
indication of a dynamic automation type. 
Class Propagation 

FIG. 22 is a flowchart illustrating steps taken to propagate 
the automation class of an automation node to another 
automation node. In response to a user dropping a first 
automation node in a VI block diagram, the block diagram 
editor 64 invokes a method of the first automation node to 
display the first automation node in step 540, as shown in 
FIG. 23. In response to a user dropping a second automation 
node in a VI block diagram, the block diagram editor 264 
invokes a method of the second automation node to display 15 
the second automation node in step 542. 

The first automation node is one of an automation open 
node, an automation invoke node, an automation property 
node, and an automation refnum. The second automation 
node is one of an automation open node, an automation 20 
invoke node, an automation property node, and an automa- 
tion close node. Each of the automation nodes, has a refnum 
input terminal and a refhum output terminal for receiving 
and providing, respectively, a type descriptor which includes 
an automation class identifier and a type library identifier 25 
which the automation class is in. However, the automation 
refnum only has a refnum output terminal and the automa- 
tion close node only has a refnum input terminal. 

The first automation node has a first automation class and 
the second automation node has a second automation class. 30 
The first and second automation classes may be the same or 
different. The automation class of each of the first and 
second automation nodes is set either by default when the 
automation node is dropped or directly by the user, prefer- 
ably using the "Select OLE Class" item in the automation 35 
node pop-up menu, as shown in FIG. 30 

In response to a user wiring the first and second automa- 
tion nodes together, the block diagram editor 264 displays a 
wire connecting the refiaum output terminal of the first 
automation node to the refnum input terminal of the second 40 
automation node in step 544. In response to the user wiring 
the first and second automation nodes together, the automa- 
tion class of the first automation node is propagated to the 
second automation node in step 546. That is, the second 
automation node receives the first automation class in the 45 
type descriptor from the first automation node and changes 
the automation class of the second automation node to the 
first automation class if the second automation class is 
different from the first automation class. 

FIG. 24 shows first and second automation nodes prior to 50 
being wired together and FIG. 25 shows the automation 
nodes after being wired together, i.e., after the automation 
class propagation has occurred. It is noted that the class of 
the second automation node is now the same as the class of 
the first automation node. 55 

Referring now to FIG. 26, a flowchart illustrating steps 
taken to propagate the automation class of an automation 
node to another automation node is shown. In response to a 
user dropping a first automation node in a VI block diagram, 
the block diagram editor 264 invokes a method of the first 60 
automation node to display the first automation node in step 
550. In response to a user dropping a second automation 
node in a VI block diagram, the block diagram editor 264 
invokes a method of the second automation node to display 
the second automation node in step 552. 65 

The first automation node is one of an automation open 
node, an automation invoke node, an automation property 



node, and an automation refnum. The second automation 
node is one of an automation open node, an automation 
invoke node, an automation property node, and an automa- 
tion close node. Each of the automation nodes, has a refnum 
input terminal and a refnum output terminal for receiving 
and providing, respectively, a type descriptor which includes 
an automation class identifier and a type library identifier 
which the automation class is in. However, the automation 
close node only has a refnum input terminal and the auto- 
mation refnum has either only a output terminal or an input 
terminal depending upon whether or not it is a control or an 
indicator, respectively. 

The first and second automation nodes have a first auto- 
mation class. The automation class of each of the first and 
second automation nodes is set either by default when the 
automation node is dropped or directly by the user, prefer- 
ably using "Select OLE Class" item in the automation node 
pop-up menu, as shown in FIG. 30. In addition, the auto- 
mation class of the automation nodes may have previously 
been set via the class propagation steps described in the 
flowcharts of FIG. 22 or FIG. 26. 

In response to a user wiring the first and second automa- 
tion nodes together, the block diagram editor 264 displays a 
wire connecting the refhum output terminal of the first 
automation node to the refnum input terminal of the second 
automation node in step 554. 

In response to a user requesting to change the first 
automation node to a second automation class, the first 
automation node changes the automation node to be of the 
second automation class in step 556. 

In response to the user changing the first automation node 
to a second automation class, the automation class of the first 
automation node is propagated to the second automation 
node in step 558. That is, the second automation node 
receives the second automation class in the type descriptor 
from the first automation node and changes the automation 
class of the second automation node to the second automa- 
tion class if the second automation class is different from the 
first automation class. 

FIG. 27 shows first and second automation nodes prior to 
changing the first automation node to be of the second 
automation class and FIG. 28 shows the automation nodes 
after changing the first automation node to be of the second 
automation class, i.e., after the automation class propagation 
has occurred. It is noted that the class of the second 
automation node is now the same as the class of the first 
automation node. 
Type Propagation Checking 

Referring now to FIG. 29, a flowchart illustrating steps 
taken to perform type propagation checking of automation 
invoke nodes and automation property nodes is shown. In 
general, the method described in FIG. 29 applies to both 
automation invoke nodes and automation property nodes, 
with differences noted. Hence, for clarity, an automation 
invoke node and an automation property node are referred to 
generically as an automation node with respect to FIGS. 29 
through 37. Likewise, the method of an automation invoke 
node and the properties of an automation property node are 
referred to as method/property where either apply. 

A user creates an automation node, i.e., an automation 
invoke node or an automation property node, in order to 
invoke methods/properties of an object instantiated from an 
automation class. Preferably, the user drags an automation 
node from the automation nodes palette of FIG. 7 and drops 
the automation node in a block diagram. In response to the 
user dropping the automation node in the block diagram, the 
block diagram editor 264 invokes a method on the automa- 
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tion node to display an automation node icon in the block a valid condition includes a color for each terminal of the 

diagram, in step 600. method which indicates the data type of the terminal, 

The automation node displayed has an associated first wherein the color is not a color which indicates an invalid 

automation class associated with it. In one case, the first condition. In one embodiment, the color which indicates an 

automation class is a default automation class. In another 5 invalid condition is black. 

case, the first automation class is selected by the user. In this In me case that the automation node is an automation 

case the user, preferably, pops up on the automation node property node the indication of a valid condition preferably 

and selects the first automation class from a list of previously ™hxdes displaying the property in a color indicative of a 

selected automation classes in the pop-up menu as shown in valid condition. In one embodiment, a color which indicates 

FIG. 30, or from a list of the automation classes in the 10 a ^ C0 t ^ lon f clude / t < * color f ° r ea * h pr ° P f rty **** 

system as shown in FIG. 11. In another case, the automation ^f^^ ^ t^Ltt ESJ^v!^ ?™ 

: - , t . j . j * 4 not a color which indicates an invalid condition. In one 

class of the automation node .s propagated to the automation embodiment & e color whidl „ inva]id condition 

node trom another automation node as described in FIG. 22 ^ black 

or FIG. 26. If the method/property of the automation node is not valid 

In response to the user selecting a method/property for the 15 f or me sec0 nd automation class, the block diagram editor 

automation node, the automation node selects the user- 264 displays an indication of an invalid condition, in step 

selected method/property to be invoked by the automation 610. 

node in step 602. The automation node displays the selected In the case* that the automation node is an automation 

method/property in the automation node. invoke node, for the first and second types of user input, the 

In step 604, the class of the automation node is changed 20 indication of an invalid condition preferably includes dis- 

to be of a second automation class in response to user input. playing a broken wire. In one embodiment, a broken wire is 

Preferably, the user input may be of three different types. a dashed wire, as shown in FIG. 31. For the third type of user 

The first type of user input is the user wiring the refnum input, the indication of an invalid condition preferably 

input terminal of the, automation node to the refnum output includes displaying at least a portion of the automation 

terminal of second automation node, such as an automation 25 invoke node in a color which indicates an invalid condition, 

open node, automation property node, or automation invoke In one embodiment, a color which indicates an invalid 

node. The second automation node propagates its automa- condition is black. 

tion class, i.e., a second automation class, to the automation In the case that the automation node is an automation 

node, as described in the flowchart of FIG. 22. The second property node the indication of an invalid condition prefer- 

automation class may or may not be different from the first 30 ably includes displaying at least a portion of the automation 

automation class, i.e., from the automation class of the property node in a color which indicates an invalid condi- 

automation node prior to the wiring. tion. In one embodiment, a color which indicates an invalid 

The second type of user input is changing the automation condition is black, 

class of a second automation node, whose refnum output In the case where the automation node is an automation 

terminal is already wired to the refnum input terminal of the 35 property node, the type propagation includes performing 

automation node, from the first automation class to the steps 608, 610 and 614 for each of the properties of the 

second automation class. As in the first type of user input, automation property node. 

the second automation node propagates its automation class, If the method/property of the automation node is not valid 

i.e., the second automation class, to the automation node, as for the second automation class, the block diagram editor 

described in the flowchart of FIG. 26. 40 264 further displays an error message in an error window, as 

The third type of user input is the user selecting the shown in FIG. 32, in step 612. In one embodiment, if the 

second automation class from a list of automation classes method/property of the automation node is not valid for the 

directly, preferably, via either the pop-up menu of the second automation class, the graphical programming envi- 

automation node as shown in FIG. 11, or the browse list as ronment prevents execution of the virtual instrument, in step 

shown in FIG. 12. When the user selects a new automation 45 614. That is the graphical programming environment pre- 

class from one of the two lists of classes, the automation vents the automation node from invoking the associated 

node changes its class to the newly selected second auto- method/property. 

mation class. Referring now to FIG. 33, a flowchart illustrating in more 

In response to the user changing the automation node to detail the step 606 of FIG. 29 of performing type propaga- 

be of the second automation class, the automation node 50 tion is shown. In response to the user changing the automa- 

performs type propagation checking to determine if the tion node to be of the second automation class, the automa- 

method/property is valid for the second automation class, in tion node passes information to the object manager 268 (of 

step 606. The automation node makes this determination in FIG. 3) in step 620. The information passed includes infor- 

step 608. Performing the type propagation checking of step mation identifying the method/property of the automation 

606 will be described in more detail below with reference to 55 node, information identifying the second automation class, 

FIG. 33. and information identifying a type library, of the type 

If the method/property of the automation node is valid for libraries 270 (of FIG. 3), which the second automation class 

the second automation class, the block diagram editor 264 is in. Preferably, the automation node invokes a function of 

displays an indication of a valid condition, in step 614. the object manager 268 which returns a value indicating 

In the case that the automation node is an automation 60 whether or not the method/property is a valid method/ 

invoke node, for the first and second types of user input, the property for the second automation class, i.e., whether or not 

indication of a valid condition preferably includes display- the second automation class defines the method/property, 

ing a valid wire. In one embodiment, a valid wire is a solid Preferably, the automation node receives the information in 

wire. For the third type of user input, the indication of a valid a type descriptor, described above, via the refnum input 

condition preferably includes displaying at least a portion of 65 terminal of the automation node. 

the automation invoke node in a color which indicates a In response to the automation node passing the inform a- 

valid condition. In one embodiment, a color which indicates tion to the object manager 268, the object 268 requests a list 
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of valid methods/properties of the second automation class 
from the type library specified in the passed information in 
step 622. The type library includes information specifying 
the methods and properties defined by each class in the type 
library. 5 

The type library returns the requested list and the object 
manager 268 receives the requested list from the type library 
and creates a data structure including the list of valid 
methods/properties of the second automation class in step 
624. 10 

In one embodiment, the object manager 268 maintains the 
data structure created and determines in response to step 620 
whether or not the list of valid methods/properties exists. If 
the list already exists, the object manager 268 does not 
perform step 622. 15 

The object manager 268 searches the list of valid 
methods/properties in the data structure in step 626 and 
determines if the method/property is valid, i.e., present in the 
list, in step 628. If the specified method/property is present 
in the list of valid methods/properties, the object manager 20 
268 returns a value indicating a valid method/property in 
step 630. If the specified method/property is not present in 
the list of valid methods/properties, the object manager 268 
returns a value indicating an invalid method/property in step 
632. 25 

FIGS. 34, 35 and 36 are screen shots illustrating a help 
screen for an automation open node, an automation property 
node, and an automation invoke node, respectively. The help 
screens illustrate the various terminals of the automation 
nodes. 30 

FIGS. 37-52: Second Embodiment 

FIGS. 37-52 illustrate a second embodiment of the 
present invention. This second embodiment is a specific 
embodiment of FIGS. 8-36, where the object whose capa- 35 
bilities are being accessed is an application, such as a 
graphical program application, e.g., Lab VIEW. In this 
embodiment, the object node is referred to as a "call by 
reference node". The call by reference node is essentially an 
invoke node as described above which can invoke or call 40 
only a run method on an application. Thus a call by reference 
node is a specific implementation or subset of the invoke 
node. It is noted that either an invoke node or a call by 
reference node may be used in this embodiment, as desired. 
FIG. 37 — Graphical Programming Environment 45 

FIG. 37 is a block diagram illustrating the relationship of 
portions of the instrumentation control system 100 and 160 
(of FIGS. 1 and 1A). FIG. 37 is similar to FIG. 3 described 
above, with changes to certain names of the software blocks 
to illustrate the specific nature of this embodiment. Elements 50 
in FIG. 37 which are identical to elements in FIG. 3 have the 
same reference numerals for convenience. Elements in FIG. 
37 which are specific implementations of elements in FIG. 
3 have the same reference numerals with an "A" following 
the numeral. Preferably, the elements shown in FIG. 37 55 
(with the exception of the hardware instrument 254) are 
software elements which are executed on the computer 102 
(of FIGS. 1 and 1A). 

This embodiment is used to create a client graphical 
program which can programmatically access server capa- 60 
bilities of an application, such as a graphical program 
application or program, e.g., Lab VIEW or a VL The present 
invention is also useable to create a client graphical program 
portion which is a part of a larger graphical program. 

In the preferred embodiment, a programmer employs a 65 
front panel editor 262, a block diagram editor 264, and a 
connector pane/icon editor 272 of a graphical programming 



environment to produce a graphical program. In the instru- 
mentation application of the preferred embodiment, the 
graphical program is referred to as a virtual instrument (VI) 
50. The block diagram editor 264 generates executable 
instructions, i.e., machine language instructions, in response 
to the client virtual instrument or VI 50. The VI 50 devel- 
oped by the programmer is executed by an execution sub- 
system 256 of the graphical programming environment to 
control an instrument 254. The instrument 254 is illustrative 
of instruments such as those of FIG. 1 and 1A. 

Referring again to FIG. 37, the graphical programming 
environment further comprises VI Server re mum controls 
274A. The front panel editor 262 is operable to generate a VI 
front panel which may include one or more of the VI Server 
refnum controls 274A. The VI Server refnum controls 274A 
communicate with the VI Server object manager 268 to 
obtain or provide information regarding class libraries 270 
in the system. 

The graphical programming environment further com- 
prises VI Server function nodes 26 6 A. The VI Server 
function nodes 266 A are shown in FIGS. 39-42 and FIGS. 
34-36. The VI Server function nodes 26 6 A comprise an 
Open Application Reference node, an Open VI Reference 
node, a Close Application or VI Reference node, a Call by 
Reference Node, a Property node and an Invoke node. The 
Call by Reference Node, the Property node and the Invoke 
node can be referred to generically as access nodes, since 
they access functionality or capabilities of a server graphical 
program or a server graphical programming application. 

The block diagram editor 264 is operable to create a VI 
block diagram, or block diagram. The block diagram editor 
264 communicates with the VI Server function nodes 26 6 A, 
which in turn communicate with the VI Server object 
manager 268. The object manager 268 accesses class librar- 
ies 270 to acquire information necessary to perform class 
and object management operations. 

Advantageously, the graphical programming 
environment, and in particular the VI Server refnum controls 
274A, the VI Server function nodes 266A, the VI Server 
object manager 68, and the VI Server run-time library 258 A, 
enable a graphical program to instantiate objects from the 
same or other Lab VIEW applications or graphical programs, 
and to remotely call Vis as well as invoke properties and 
methods of the instantiated objects. 

The graphical programming environment further prefer- 
ably comprises a connector pane/icon editor 272 for forming 
VPs into subVTs, i.e., a VI which may be used as a 
graphical programming element in another VI. The reader is 
referred to U.S. Pat. No. 5,301,336 for more information 
about the subVTs and the icon editor 272. 

The execution subsystem 256 executes the executable 
instructions constructed from a block diagram of the VI 50. 
For more information about the execution subsystem 56 the 
reader is referred to U.S. Pat. No. 5,481,741. 

Preferably, the VI 250A calls Vis and/or invokes methods 
and properties of application or VI objects (Lab VIEW server 
252A) indirectly through the services of the VI Server 
manager run-time library 258A. Examples of the Lab VIEW 
server 252A include a Lab VIEW application, or a graphical 
program or VI. The server application or VI 252 A may be 
located on the same computer or on another computer. The 
VI 250A controls the instrument 254 through an instrument 
device driver 253 which includes executable functions 
which are called by the VI 250A to perform operations in 
order to control the instrument 254. 

When the Lab VIEW server 252Ais located on a different 
computer, the block diagram appears as shown in FIG. 37 A. 
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In an embodiment where the two computers are connected 
through a TCP/IP connection, such as the Internet, this 
system further includes TCP client code and TCP server 
code coupled between the VI Server run-time library 258A 
and the LabVIEW Server 252A, which performs the 5 
required communication. 

The VI Server nodes 266 and VI Server refnum controls 
274A comprise classes and objects, according to the notion 
of classes and objects in the art of object-oriented program- 
ming. Each of the VI Server nodes 266 and the VI Server 10 
refnum controls 274A comprise properties and methods. The 
methods include a method for drawing an icon representa- 
tion of the object on the video display 222 of the computer 
102 either in the VI block diagram or front panel, a method 
for generating code associated with the different functions of 15 
each node or control, and a method for performing class or 
type propagation checking. The operation of the VI Server 
nodes 26 6 A and the VI Server controls 274A will be 
explained in more detail below. 

As mentioned above, the client graphical program 250A 20 
is not necessarily related to controlling an instrument, but 
rather the graphical program 250Amay be for any of various 
applications. That is, the client may have an application 
other than instrumentation control. 

Advantageously, the graphical system and method for 25 
producing the graphical program or VI 250A has a number 
of benefits. These benefits include the ability to program- 
matically access functionality from the same or other graphi- 
cal programming applications or graphical programs. This 
results in a reduction in the development time required to 30 
create the VI 250A as well as reduction of the number of 
code defects in the VI 250A. Yet another benefit is the 
simplicity of programming which makes the development of 
a graphical program, such as an instrumentation control 
program, more practical for a larger number of people, i.e., 35 
those who might not have the skills, or resources to develop 
the skills, to develop programs according to more conven- 
tional text -based methods. The system and method also 
provides class propagation, class checking and type check- 
ing in a graphical programming environment, discussed 40 
further below, thus simplifying program development. 
Overview of the Embodiment 

The graphical programming system, e.g. LabVIEW, 
exports many of its capabilities to other applications of 
graphical programs through a new set of features, collec- 45 
tively referred to as VI server. This embodiment includes 
new diagram function nodes, referred to as VI Server 
function nodes (266AFIG. 37), illustrated in FIGS. 39-42, 
as well as the property and invoke nodes illustrated in FIGS. 
35 and 36, which allow the user to access these capabilities 50 
from within the graphical programming system. The user 
can thus create diagrams in LabVIEW that get/set properties 
and invoke operations on both LabVIEW applications and 
graphical programs (Vis) within the respective user's local 
version of LabVIEW as well as on other copies of LabVIEW 55 
or graphical programs on a network, such as a TCP/IP 
network. The user can also access these VI server capabili- 
ties from other clients such as an ActiveX client, e.g., a 
Visual Basic application or Microsoft Excel. 
FIG. 38 — VI Server Refnum Controls 60 

The VI server functionality of this embodiment is pref- 
erably accessed through references to two main classes of 
objects, these being the Application object and the VI object. 
The VI object is further sub-divided into two classes of 
objects: the Generic VI and the Strictly typed VI. FIG. 38 65 
illustrates the front panel refnum controls for the 
Application, Generic VI, and Strictly-typed VI data types. 



As shown in FIG. 38, the image in each refnum icon 
indicates the type of the refnum. The Application class 
refnum icon displays the LabVIEW application icon. The 
Generic VI class refnum icon displays the VI file icon. The 
Strictly- typed VI class refnum icon depicts the connector 
pane that defines the class. 

The front panel refnum comprises a reference to an object. 
Thus, the Application refnum provides a reference to a 
graphical programming application, e.g. a LabVIEW 
application, the generic VI refnum provides a reference to a 
generic virtual instrument or generic graphical program, and 
the strictly typed VI refnum provides a reference to a 
specified graphical program or VI. 

In the preferred embodiment, the user selects a VI Server 
front panel refnum control and places this refnum control in 
a front panel of a virtual instrument or graphical program. 
The user then configures the refnum to be either an Appli- 
cation refnum, a Generic VI refnum, or a Strictly- typed VI 
refnum. Once the user has configured the refnum control to 
one of these three types, the refnum control takes on the 
respective appearance by the class selected by the user. For 
example, if the user drops the front panel refnum control on 
the front panel and configures the refnum to be of the 
Application class, the refnum takes on the Application icon 
appearance shown in FIG. 4. 

When the user drops or places the VI Server refnum in the 
front panel and configures the refnum, corresponding ter- 
minals appear in the block diagram. These terminals provide 
the information on the application or graphical program 
referenced by the refnum. In an alternate embodiment, the 
user places the refnum directly in the block diagram. 

In general, a Generic VT reference is used to perform 
editing operations (e.g., setting properties or invoking 
functions) on any VI. A Strictly -typed VI reference is used 
to call a dynamically loaded VI as a sub-VI, and to perform 
operations that do not edit or change the VI, such as setting 
its Front Panel window size or location. An application 
reference is used to get or set properties on the application, 
or invoke methods on the application, 
FIGS. 39-42: VI Server Functions Nodes 

FIGS. 39^2 and FIGS. 35-36 illustrate the VI server 
function nodes according to the preferred embodiment of the 
invention. As noted above, these function nodes or diagram 
functions can be used in a graphical program to access 
capabilities of other LabVIEW applications or Vis. More 
specifically, these diagram functions can be placed in a 
graphical program or virtual instrument and can be used to 
programmatically obtain references to specific instances of 
the above classes. For example, an instance of the applica- 
tion class could be the LabVIEW graphical programming 
application running on the respective user's system, or a 
LabVIEW application running on another computer system 
which is connected to the user's computer system through a 
network, such as the Intern et. Thus, an instance of the 
application class could be a LabVIEW application running 
anywhere in the world on the Internet, even on a different 
platform. In a similar manner, an instance of the Generic VI 
class could be any VI on the user's computer or any exported 
Vis in a remote version of LabVIEW. An instance of the 
Strictly-typed VI class could be a specified VI running in the 
user's LabVIEW application or any other specified VI 
residing the user's computer or on a remote computer 
system. 

It is noted that, for security, the user can configure the 
LabVIEW application to allow and disallow certain Internet 
addresses from establishing connections, as well as allow 
and disallow certain Vis from being referenced by external 
programs. 
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Each of the VI Server function nodes are described below. 
FIG. 39 — Open Application Reference node 

FIG. 39 illustrates the Open Application Reference node. 
The Open Application Reference node returns a reference to 
a VI Server application running on the specified computer. 5 
If an empty string is specified for machine name, then the 
node returns a reference to the local Lab VIEW application 
in which this function is running. If a machine name is 
specified, then the node attempts to establish a TCP con- 
nection with a remote VI Server on that machine on the 10 
specified port. 

The application reference output can be used as an input 
to the Property and Invoke nodes to get or set properties and 
invoke methods on the application. The application refer- 
ence output is used as the input to the Open VI Reference 15 
function to obtain references to Vis in that application. The 
reference is closed with the Close Application or VI Refer- 
ence function. If the user forgets to close this reference, the 
reference closes automatically when the top level VI asso- 
ciated with this function finishes executing. However, clos- 20 
ing the reference operates to conserve the resources involved 
in maintaining the connection. 

The following describes the inputs and outputs of the 
Open Application Reference node: 

machine name is the address of the computer that runs a 25 
copy of Lab VIEW to which it is desired to establish a 
connection. This address can be in dotted decimal 
notation (such as 130.164.15.250) or domain name 
notation (such as foo.natinst.com). An empty string will 
cause this function to return a reference to the local 30 
Lab VIEW. 

port number is the port on which the remote LabVIEW 
application is listening. If port number is not wired, the 
default VI Server listener port number (5151) is used. 

error in describes error conditions that occur prior to the 
execution of this function. The default input of this 
cluster is no error. If the error Boolean of this cluster is 
True, the Open Application Reference function will do 
nothing but pass through the error via the error out ^ 
output. 

application reference is the reference to the specified 
application. 

error out contains error information. If error in indicates 
an error, error out contains the same error information. 45 
Otherwise it describes the error status that this function 
produces. 
FIG. 40 — Open VI Reference node 

FIG. 40 illustrates the Open VI Reference node. The Open 
VI Reference node returns a reference to a VI specified by so 
a name string or path to the VTs location on disk. In the 
current embodiment, references can only be obtained to 
standard Vis. This excludes Control, Typedef, and Global 
Vis. In the preferred embodiment, the Open VI Reference 
node can be used to obtain a reference to any VI. 55 

References to Vis in another LabVIEW application are 
obtained by wiring an application reference (obtained from 
the Open Application Reference function) to this function. 
In this case, the path input refers to the file system on the 
remote LabVIEW computer. If a reference is wired to the 60 
local LabVIEW application the same behavior is obtained as 
if nothing had been wired to the application reference input. 

If editing operations are to be performed on the referenced 
VI, and the VI has a password-protected diagram, the 
password is provided to the password string input. If the 65 
incorrect password is provided, the Open VI Reference 
function returns an error and an invalid VI reference. If no 
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password is provided when opening a reference to a VI that 
is password protected, the reference can still be obtained, 
operations can only be performed that do not edit the VI. 

If the specified VI is to be called through the Call By 
Reference function, a strictly-typed VI reference is wired to 
the type specifier input. The function ignores the value of 
this input. Only the input's type — the connector pane 
information — is used. By specifying this type, the Open VI 
Reference function verifies at run time that the referenced 
VTs connector pane matches that of the type specifier input. 

It is noted that, if a Generic VI refnum type is wired to the 
type specifier input, this results in the same behavior as if the 
type specifier input had not been wired at all. 

If the type specifier input is wired with a strictly-typed VI 
refhum, the VI must meet several requirements before the VI 
reference is returned successfully: 

1) The VI cannot be broken for any reason. 

2) The VI must be runnable as a subVI, that is, it cannot 
be active as a top-level VI (unless the VI is re-entrant). 

3) The connector pane of the VI must match that of the 
type specifier. 

If the user forgets to close this reference using a close 
reference node, the reference closes automatically when the 
top-level VI associated with this function finishes executing. 
However, closing the reference operates to conserve the 
resources involved in maintaining the connection. 

If a strictly-typed reference to a reentrant VI is obtained, 
a dedicated data space is allocated for that reference. Hiis 
data space is preferably always used and is used only in 
conjunction with the output VI reference. This can lead to 
some new behaviors in LabVIEW. For example, parallel 
calls (using the Call By Reference node) to a reentrant VI 
using the same VI reference does not execute in parallel, but 
executes serially, one after the other. As another example, a 
reentrant VI could get a reference to itself (allocating a new 
data space) and call itself recursively through the Call By 
Reference node. It is noted that allocating a data space 
dynamically is both time consuming and memory consum- 
ing and is not generally recommended for implementing 
recursive algorithms. 

A VI reference is similar to what is known as a function 
pointer in other languages. However, in LabVIEW, these 
function pointers also can be used to call Vis across the 
network. 

The following describes the inputs and outputs of the 
Open VI Reference node: 

application reference is a reference to a LabVIEW appli- 
cation. If this input is left unwired, the reference is to 
an application on the local version of LabVIEW. If the 
input is wired, and the reference is to a remote version 
of LabVIEW, then the remote LabVIEW is queried to 
return the VI reference. 

type specifier is used for its data type only. The value of 
the input is ignored. TTie data type of the type specifier 
input determines the data type of the vi reference 
output. The type specifier input is used if it is desired 
to use the output reference to call the VI with the Call 
By Reference node. If the type specifier input is left 
unwired, the output is a Generic VI reference. 

VI name or path is polymorphic and can accept a string 
containing the name of the desired VI, or a path 
containing the complete path (including the name) to 
the desired VI. If a name string is wired, then the VI 
must already be in memory. If a path is wired and the 
VI is already in memory, the VI in memory is obtained, 
whether its path is the same as the input or not. If the 
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VI is not in memory, then the VI must be at the 

specified path for this function to succeed. If the VI is 

at that location, the VI is loaded into memory, 
error in describes error conditions that occur prior to the 

execution of this function. The default input of this 

cluster is no error, 
password is the plain-text file for the VI. If the VI is not 

password protected, the input is ignored. If the VI is 

password protected and an incorrect password is 

entered, the VI can be referenced, but the VI cannot be 

edited through that VI reference, 
vi reference is the refhum associated with the requested 

VI. If the function fails, "not-a-refnum" is returned, 
error out contains error information. If error in indicates 

an error, error out contains the same error information. 

Otherwise error out describes the error status that this 

VI produces. 

If the user specifies a remote version of Lab VIEW by the 
application reference input, the path is interpreted on the 
remote machine in the context of the remote file system. The 
path is expressed using the local computer's path separators, 
but is translated to the remote computer's path separators 
when the request arrives there. For example, to reference a 
VI on a Macintosh at My HD:LabVIEW VIs.foo.vi from a 
Windows application, the Window's path syntax: My 
HD:\LabVIEW VIs\foo.vi would be used. Conversely, to 
reference a VI on a Windows computer at C:\labviewfoo.vi 
from a Macintosh application, the Macintosh path syntax: C: 
labview.foo.vi would be used. 

The open nodes in FIGS. 39 and 40 are similar to the 
Automation Open node described in FIG. 34. 
FIG. 41 — Close Application or VI Reference 

FIG. 41 illustrates the Close Application or VI Reference 
node. The Close Application or VI Reference node closes an 
open VI or the TCP connection to an open copy of Lab- 
VIEW. 

The following describes the inputs and outputs of the 
Close Application or VI Reference node: 

application or vi reference is the refmim associated with 
an open VI or an open copy of Lab VIEW. 

error in describes error conditions that occur prior to the 
execution of this function. The default input of this 
cluster is no error. 

error out contains error information. If error in indicates 
an error, error out contains the same error information. 
Otherwise it describes the error status that this VI 
produces. 
FIG. 42— Call By Reference Node 

FIG. 42 illustrates the Call By Reference node. As dis- 
cussed above, the call by reference node is a particular 
instance of an invoke node, where the method being invoked 
is a run method. The Call By Reference node is very similar 
to a sub-VI node in that either can be used to call a VI. 
However, a sub-VI node is statically linked to a particular VI 
that the user determines when he/she drops the node on the 
diagram. With the Call By Reference node, the VI that is 
called is determined dynamically at run time by the value of 
the VI reference wired to the reference input at the top of the 
node. In fact, it is possible that the VI which is called by the 
Call By Reference node might be on a different computer. 

The top of the Call By Reference node includes four 
terminals: an input/output pair of flow through VI reference 
terminals, and an input/output pair of flow through error 
clusters. Hie VI reference input accepts wires only from 
strictly-typed VI references. Below these terminals is an area 
within which a connector pane resides (is displayed) that is 



57,805 Bl 

38 

identical to that of a VI with its terminals showing (rather 
than its icon). The connector pane of the strictly- typed VI 
reference input determines the pattern and data types of this 
connector pane which is displayed in the Call By Reference 

5 node icon. The user wires to these terminals just as he/she 
would to a normal sub-VI. 

As long as none of the terminals of the connector pane 
have wires attached to them, the connector pane will adapt 
automatically to that of the input VI reference's connector 

1Q pane. However, if any of them are wired, the node does not 
adapt automatically, and the user must explicitly change the 
connector pane (possibly breaking those wires) by popping 
up on the node and selecting the Adapt To Reference Input 
menu item. 

15 At run time there is a small amount of overhead in calling 
the VI that is not necessary in a normal sub-VI call. Hiis 
overhead comes from validating the VI reference and a few 
other bookkeeping details. However, for a call to a VI in the 
local Lab VIEW, this overhead should be insignificant for all 

2Q but the smallest sub Vis. Calling a VI located in another 
Lab VIEW application (across the network) involves con- 
siderably more overhead. 

The following describes the inputs and outputs of the Call 
By Reference node: 

25 reference is the refnum associated with a VI that is already 
open. 

error in describes error conditions that occur prior to the 

execution of this function. The default input of this 

cluster is do error. 
30 dup reference has the same value as reference. 

error out contains error information. If error in indicates 

an error, error out contains the same error information. 

Otherwise, it describes the error status that this VI 

produces. 

35 As noted above, the call by reference node is a specific 
implementation of the invoke node described with reference 
to FIG. 36. More specifically, the call by reference node is 
an invoke node which can only invoke a run method on an 
application or program. 

40 Property Node 

As discussed above, FIG. 35 illustrates the Property node. 
In this embodiment, the Property node sets (writes) or gets 
(reads) VI and application property information. In this 
embodiment, to select the VI or application class, the user 

45 pop ups on the node and selects the Select Lab VIEW Class 
submenu. To set an application class, the user selects Appli- 
cation. To set a VI class, the user selects Generic VI, or wires 
the VI or application refnum to reference and the node 
choices change accordingly. 

50 To select a specific property, the user pop ups on one of 
the name terminals and selects Properties. To set property 
information, the user pop ups and selects Change to Write. 
To get property information the user pop ups and selects 
Change to Read. Some properties are read only, so Change 

55 to Write cannot be seen in the popup menu. The Property 
Node works the same way as Attribute Nodes. If the user 
desires to add items to the node, the user pop ups and selects 
Add Element or clicks and drags the node to expand the 
number of items in the node. The properties are changed in 

60 the order from top to bottom. If an error occurs on one of the 
properties, the node stops at that property and returns an 
error. In this case, no further properties are handled. The 
error string reports which property caused the error. If the 
small direction arrow on a property is on the left, then the 

65 property value is being set. If the small direction arrow on 
the property is on the right, the user is getting the property 
value. Each property name has a short or long name which 
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can be changed by popping up and selecting Name Format. The user drops the VI refnum control on a front panel 

Another name format is no name where only the type is from the Controls»Path and Refnum palette. The user 

displayed for each property. The VI and application prop- chooses the refnum called Application or VI Reference. By 

erties that can be used with the Property node are more fully default, the type of this refnum is the Application class. To 

described below in sections titled Properties — Virtual 5 change the refnum control's type, the user pops up on this 

Instrument Class and Properties — Application Class. control and selects the Select Lab VIEW Class submenu, as 

The inputs and outputs of the Property node are described shown in FIG. 14. In this submenu the choices are 

bel6w. Application, Generic VI, Browse ... and a Strictly Typed 

reference is the refnum associated with an open VI or an Vis palette submenu of previously browsed and selected 

open copy of Lab VIEW across a TCP connection. 10 Strictly-typed VI classes, 
error in describes error conditions that occur prior to the When the user selects Browse . . . , the Choose VI to open 
execution of this function. The default input of this dialog box appears asking the user to select a VI from the file 
cluster is no error. system. The connector pane of the VI that is selected 
dup reference has the same value as reference. determines the type of the Strictly-typed VI refnum. Select- 
error out contains error information. If error in indicates 15 ing the VI establishes that particular refnum control as the 
an error, error out contains the same error information. class of Vis (that is, Vis with similar connector panes) that 
Otherwise error out describes the error status that this the node passes. It is noted that, in the preferred 
VI produces. embodiment, only the connector pane of the selected VI is 
Invoke Node used to establish the refnum's type. Lab VIEW does not 
As discussed above, FIG. 36 illustrates the Invoke node. make any assoc i at ion between the refnum control and the 
The Invoke node invokes a method or action on a VL Most ^ selected yr ]n particular establishing a refnum's type does 
me hoo^haveparametersassociatedwiththem Toselectthe Qot ide a r e fercncc to the se l C cted VI. 
method, the user pops up anywhere on the node and select ^ {hc user faas kced fo 
Methods. Once the user selects the method, the associated , , . , , \ . tl 4 , . , 
parameters appear as shown in FIG. 10. The user can then ? anel ^ h f ^f ed a Stactiy-typed class the correspond- 
set and get the parameter values. Parameters with a white 25 'm terminals in the block diagram provide the respective 
background are required inputs and the parameters with a cla ^f in f ormatlon - 

gray background are recommended inputs. The VI and user then dro P s or P laces aQ °P cn reference node in 

application methods and their associated parameters that can the graphical program, as shown in FIG. 43. For a VI which 

be used with the Invoke node are discussed below. uses Strictly-typed VI references, the open reference node is 

The inputs and outputs of the Invoke node are as follows: 30 tne Open VI Reference node. As noted above, in general, a 

auto refnum in is the refnum associated with a VI on Generic VI reference is used to perform editing operations 

which the user desires to perform an action, error in ( e *g*> setting properties or invoking functions) on any VI. A 

describes error conditions that occur prior to the execu- Strictly-typed VI reference is used to call a dynamically 

tion of this function. The default input of this cluster is loaded VI as a sub -VI, and to perform operations that do not 

no error. 35 edit or change the VI, such as setting its Front Panel window 

dup Auto Refnum has the same value as Auto Refnum In. SIze or location. 

error out contains error information. If error in indicates ^ method specifies whether Open VI Reference opens 

an error, error out contains the same error information. a Gener ic VI reference or a Strictly-typed VI reference at the 

Otherwise error out describes the error status that this P oint where the °P ens the reference to the VI. To get a 

VI produces. 40 Strictly-typed VI reference, the user wires a type specifier 

FIG. 43— Graphical Program using Strictly-Typed VI Ref- control to the "type specifier" input of the Open VI Refer- 

erences ence function, as shown in FIG. 11. The type specifier 

FIG. 43 illustrates a block diagram or graphical program specifies the required connector pane of the VI to be called 

which uses Strictly-typed VI references. It is noted that the when the VI is loaded at ™ time * tv P e specifier also 

order in which the various nodes are placed in the diagram 45 determines the type of the VI reference output of the Open 

and wired up is not important, and various orders may be VI Reference function. When the user wires this output to 

used, as desired. tne Call By Reference node, the node adapts to have the 

In order to create the graphical program, first the user same set of in P ut ™ d 0Ut P ul terminals as the original type 

drops or places a VI Server refnum in a front panel of the specifier. In other words, the Call By Reference node icon 

graphical program. When the user places the VI Server so changes appearance to display the connector pane based on 

refnum in the front panel, corresponding terminals appear in lts rec eived input. 

the block diagram. There are two different situations in ^ °P eo vr Reference function does not use the names 

which a strictly-typed VI refnum control is used. The first of in P m and outputs to determine if a VI matches the class 

and perhaps most typical is to pass a strictly-typed VI established in the node. However, class matching is fairly 

reference into a VI as a parameter. In this case, the user 55 strict and a11 of the following must match: 

connects the strictly-typed refnum control to the connector 1) connector pane pattern and orientation 

pane of the VI, and the user wires the refnum's terminal on 2) unconnected and connected terminals, and their types 

the diagram as the input to the Invoke, Property, or Call By and direction (that is, whether they are input or output) 

Reference nodes. The value of the refnum is used by each of 3) whether an input is required or not 

the these nodes to determine the VI on which it will operate, eo After the user establishes the connector panes, Lab VIEW 

The second situation occurs when a strictly-typed refnum retains them in the Strictly Typed Vis submenu, where the 

control is used as the type specifier for the Open VI user can select them again later. These connector panes are 

Reference function. In this case, the value of the control is available for a single Lab VIEW session only. After quitting 

ignored — only the type information is used by the Open VI and relaunching Lab VIEW, this palette submenu is empty 

Reference function. It is also possible to use the same 65 until more Vis are selected for their connector pane types, 

strictly-typed refnum control for both of the above situa- The user also connects a terminal to the "VI name or path" 

tions. input of the Call by Reference node to provide the name or 
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path of the VI. The user further connects other inputs of the 
Open VI Reference node, including the application refer- 
ence and any desired password. 

When the Open VI Reference runs and locates the 
requested VI (which the user specifies by either a name 
string or a full path), the Open VI Reference node checks to 
see that the connector pane of the VI matches that of the 
type -specifier input (specified by the "type specifier" 
control). If the connector pane does not match, the Open 
function fails and returns an error and an invalid reference. 
If the connector pane does match, then the Open function 
succeeds and a reference to the VI is returned. 

The user then drops a Call by Reference node in the 
graphical program or block diagram. The user then wires the 
"vi reference" output of the Open VI Reference node to the 
reference input of the Call by Reference node. As noted 
above, the VI reference input accepts wires only from 
strictly-typed VI references. 

As discussed above, the Call by Reference node displays 
a connector pane comprising input and output terminals 
corresponding to the referenced VI or graphical program. 
The Call By Reference node is very similar to a sub- VI node 
in that either can be used to call a VI. In essence, the Call 
By Reference node is a sub -VI node is statically linked to a 
particular VI that the user determines when he/she drops the 
node on the diagram. The connector pane of the strictly- 
typed VI reference input determines the pattern and data 
types of the connector pane which is displayed in the Call By 
Reference node icon. 

The user wires to the terminals on the connector pane 
displayed in the Call By Reference node icon just as he/she 
would to a normal sub-VI. Thus, as shown in FIG. 43, two 
of the inputs to the connector pane are wired to receive 
inputs, these being "device", which is a 16 bit integer, and 
a "channel" string. The remaining inputs are optional and are 
unconnected. The output of the connector pane is wired to an 
output terminal referred to as "sample" corresponding to an 
indicator on the front panel. 

Thus, the graphical program portion shown in FIG. 11 
essentially performs the same function as if the VI being 
called were present. If the graphical program portion shown 
in FIG. 43 was part of a larger graphical program, the 
graphical program portion shown in FIG. 43 would essen- 
tially perform the same function as if the VI being called 
were present as a sub-VI in the larger graphical program. 

The connector pane adapts automatically to that of the 
input VI reference's connector pane, presuming none of the 
terminals of the connector pane in the Call by Reference 
node have wires attached to them. However, if any of the 
terminals are wired, the node does not adapt automatically, 
and the user must explicitly change the connector pane 
(possibly breaking those wires) by popping up on the Call by 
Reference node and selecting the Adapt To Reference Input 
menu item. 

The user then drops the Close Application or VI Refer- 
ence node in the diagram or graphical program and connects 
the "vi reference" output of the Call by Reference node to 
the input of the "application or vi reference" input. The user 
may also wire up the error in and error out of both the Call 
by Reference node and the Close Application or VI Refer- 
ence node at this time. 

With this complete, the user has completed a client 
graphical program which operates to call a VI, wherein the 
VI may reside on the same or another computer. 

With the Call By Reference node, the VI that is called is 
determined dynamically at run time by the value of the VI 
reference wired to the reference input at the top of the node. 
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At run time there is a small amount of overhead in calling 
the VI that is not necessary in a normal sub-VI call. This 
overhead comes from validating the VI reference and a few 
other bookkeeping details. However, for a call to a VI in the 
5 local Lab VIEW, this overhead should be insignificant for all 
but the smallest sub Vis. Calling a VI located in another 
Lab VIEW application (across the network) involves con- 
siderably more overhead. 

FIG. 44— Using Generic VI References with the Property 

10 and Invoke nodes 

FIG. 44 illustrates a graphical program or block diagram 
which uses a generic VI reference and uses a property node 
to get/set properties on the generic VI and uses an invoke 
node to invoke methods on the generic VI. 

15 In order to create the graphical program, first the user 
drops or places a VI Server refnum in a front panel of the 
graphical program. When the user places the VI Server 
refnum in the front panel, corresponding terminals appear in 
the block diagram. The user drops the VI refnum control on 

20 a front panel from the Controls»Path and Refnum palette. 
The user chooses the refnum called Application or VI 
Reference. By default, the type of this refnum is the Appli- 
cation class. To change the refnum control's type, the user 
pops up on this control and selects the Select Lab VIEW 

25 Class submenu, as shown in FIG. 46. In this submenu the 
choices are Application, Generic VI, Browse . . . and a 
Strictly Typed Vis palette submenu of previously browsed 
and selected Strictly-typed VI classes. In this example, the 
user selects the Generic VI option. 

30 After the user has placed the VI Server refnum in the front 
panel and has selected a Generic VI class, the corresponding 
terminals in the block diagram provide the respective class 
information. 

The user then drops or places an open reference node in 

35 the graphical program, as shown in FIG. 43. For a VI which 
uses Generic VI references, the open reference node is the 
Open VI Reference node. It is noted that the Open Appli- 
cation node can be used to provide an application reference 
output to an input of the Open VI Reference node. As noted 

40 above, in general, a Generic VI reference is used to perform 
editing operations (e.g., setting properties or invoking 
functions) on any VI. The user wires the vi name terminal to 
the vi name or path input of the Open VI Reference node. 
The method specifies whether Open VI Reference opens 

45 a Generic VI reference or a Strictly-typed VI reference at the 
point where the user opens the reference to the VI. To get a 
Generic VI reference, the user leaves the type specifier input 
of the Open VI Reference function unconnected, as shown 
in FIG, 44. Alternatively, the user wires a Generic VI refnum 

50 to the type specifier input of the Open VI Reference func- 
tion. This type specifier also determines the type of the VI 
reference output of the Open VI Reference function. 

If the user does not wire a strictly-typed VI refnum to the 
type specifier input, then the type of the VI reference output 

55 defaults to the Generic VI class. In this case, the Open 
function does not attempt to match the connector pane, and 
so a reference to any VI can be obtained. This is done where 
the user desires to programmatically edit the VI. However, 
a Generic VI reference cannot be wired to the Call By 

60 Reference Node because, without the type specifier that 
describes the VPs connector pane, Lab VIEW does not have 
enough information to generate a correct call to the VI. 

As shown in FIG. 44, the user can then drop or place one 
or more Property nodes and/or Invoke nodes in the graphical 

65 program. As shown, each of the Property nodes and/or 
Invoke nodes in the graphical program include a reference 
input which receives the Generic VI reference output from 
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the Open VI Reference node. Each of Property nodes and/or 
Invoke nodes also include a dup reference output which is 
used to pass the reference to other nodes in the diagram. As 
shown, the dup reference output of the Property node is 
provided to the reference input of the Invoke node. 5 

As described above, the Property node sets (writes) or 
gets (reads) VI and application property information. To 
select the VI or application class, the user pop ups on the 
node and selects the Select Lab VIEW Class submenu. To set 
an application class, the user selects Application. To set a VI 10 
class, the user selects Generic VI, or wires the VI or 
application refnum to reference and the node choices change 
accordingly. 

To select a specific property, the user pop ups on one of 
the name terminals and selects Properties. To set property 15 
information, the user pop ups and selects Change to Write. 
To get property information the user pop ups and selects 
Change to Read. Some properties are read only, so Change 
to Write cannot be seen in the popup menu. The Property 
Node works the same way as Attribute Nodes. If the user 20 
desires to add items to the node, the user pop ups and selects 
Add Element or clicks and drags the node to expand the 
number of items in the node. The properties are changed in 
the order from top to bottom. 

Each property name has a short or long name which can 25 
be changed by popping up and selecting Name Format. 
Another name format is no name where only the type is 
displayed for each property. The VI and application prop- 
erties are more filly described below in sections titled 
"Properties — Virtual Instrument Class and Properties — 30 
Application Class". 

In the example of FIG. 44, the Property node is configured 
to set a property called "TO. Visible". 

As described above, the Invoke node invokes a method or 
action on a VI. Most methods have parameters associated 35 
with them. To select the method, the user pops up anywhere 
on the node and select Methods. Once the user selects the 
method, the associated parameters appear. The user can then 
set and get the parameter values. Parameters with a white 
background are required inputs and the parameters with a 40 
gray background are recommended inputs. 

In the example of FIG. 44, the Invoke node is configured 
to perform the Print VI to text method with the following 
parameters being retrieved: Text File Path, Append? and 
Format. 45 

The user then drops the Close Application or VI Refer- 
ence node in the diagram or graphical program and connects 
the "vi reference" output of the Invoke node to the input of 
the "application or vi reference" input. The user may also 
wire up the error in and error out inputs and outputs, as well 50 
as other terminals, of the Property node, the Invoke node and 
the Close Application or VI Reference node at this time. 

With this complete, the user has completed a client 
graphical program which operates to get/set properties and 
invoke methods on a VI, wherein the VI may reside on the 55 
same or another computer. 

FIG. 45 — Accessing Server Application Functionality with 
the Property and Invoke Nodes 

FIG. 45 illustrates a graphical program or block diagram 
which uses acceses capabilities of a server application, e.g., 60 
uses a property node to get/set properties on the server 
application and/or uses an invoke node to invoke methods 
on the server application. 

In order to create the graphical program, first the user 
drops or places a VI Server refnum in a front panel of the 65 
graphical program. When the user places the VI Server 
refnum in the front panel, corresponding terminals appear in 
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the block diagram. The user drops the VI refnum control on 
a front panel from the Controls))Path and Refnum palette. 
The user chooses the refnum called Application or VI 
Reference. By default, the type of this refnum is the Appli- 
cation class, and thus this class is automatically selected. 

After the user has placed the VI Server refnum in the front 
panel and has selected the Application class, the correspond- 
ing terminals in the block diagram provide the respective 
class information. 

The user then drops or places an open reference node in 
the graphical program, as shown in FIG. 45. To access 
capabilities of a server application, the open reference node 
is the Open Application Reference node. As noted above, in 
general, an Application reference is used to perform editing 
operations (e.g., setting properties or invoking functions) on 
any application. The user wires the machine name terminal 
to the machine name input of the Open Application Refer- 
ence node. 

The user then drops or places a Property node in the 
diagram, and wires the application reference output of the 
Open Application node to the input of the Property node. As 
shown, the user can then select one or more properties as 
described above. As shown, the error output of the Property 
node is connected to an Error 10 terminal. Although not 
shown in FIG. 45 the dup reference output of the Property 
node is preferably connected to the application reference 
input of a Close Application node. 
Execution 

The method further includes constructing executable 
instructions in response to the graphical program including 
the VI Server nodes. The executable instructions are oper- 
able to access capabilities of an object, such as call a 
graphical program or application. More particularly, in the 
case of a call by reference node, the executable instructions 
are operable to call or invoke a graphical program or VI, and 
in the case of a property or invoke node, the executable 
instructions are operable to get/set properties or invoke 
methods, respectively, of the instantiated object, which can 
be either a graphical program or application. The method 
then executes the executable instructions on the computer. 

During execution, the respective access node, e.g., either 
the call by reference node or the invoke or property node, in 
the client communicates with the server to obtain a reference 
to the server VI or application. The client then operates to 
create a proxy callee, and the server operates to create a 
proxy caller, to accomplish accessing capabilities in the 
server VI or server application. The operation is discussed in 
more detail below. 
Configuring the VI Server 

The user can configure which parts of the VI Server are 
available to other applications, as well as enable or disable 
particular protocols and specify which server resources are 
exported. 

1. Server Configuration 

To configure the server for external applications, the user 
selects Edit»Preferences on the server machine and select 
Server: Configuration from the drop down menu. The dialog 
box appears as shown in FIG. 47. 

The options shown in FIG. 47 specify through which 
communication protocols other applications can access the 
VI Server: TCP/IP or ActiveX protocols. If the user enables 
TCP/IP, the user must enter the Port number that client 
applications use to connect to the server. When the user 
allows other applications to connect using TCP/IP, the user 
should also configure which Internet hosts have access to the 
server. See the TCP/IP Access Configuration section for 
more information. For more information about the VI server 
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ActiveX interface, refer to U.S. provisional patent applica- 
tion Serial No. 60/056,528 tided "System and Method for 
Providing Automation Server Capabilities in Graphical Pro- 
grams" filed Aug. 21, 1997, whose inventors are Ram 
Kudukoli, Robert Dye, and Murali Parthasarathy, which is 5 
hereby incorporated by reference. 

With Server: Configuration selected, the user also speci- 
fies which server resources are available to applications that 
access the VI Server. The following server resources are 
available: io 

VI Calls allows applications to make calls to Vis on the 
server. When the user allows other applications access to 
Vis, the user should also configure which Vis they have 
access to. See the section Exported Vis Configuration for 
more information. 15 

VI Methods and Properties allows applications to read 
and set the properties of Vis on the server. When the user 
allows other applications access to Vis, the user should also 
configure which Vis they have access to. See the section 
Exported Vis Configuration for more information. 20 

Application Methods and Properties allows applications 
to read and set the properties of the server. 

In FIG. 47 above, TCP/IP server access is enabled for port 
5151 and the ActiveX server access is disabled. The server 

15 

allows remote clients to call Vis, but does not allow access 
to VI or application methods and properties. 

The default server settings have ActiveX enabled and 
TCP/IP disabled. By default, VI Calls is enabled, but VI 
Methods and Properties and Application Methods and Prop- 3Q 
erties are disabled. 

2. Exported Vis Configuration 

If the user allows remote applications to access Vis on the 
VI Server, the user should specify which Vis these appli- 
cations can access. To configure the exported Vis, the user 35 
selects Edit»Preferences on the server computer, then 
selects Server: Exported Vis from the drop down menu. The 
dialog box appears as shown in FIG. 48. 

The Server: Exported Vis options allows the user to 
specify which Vis other applications can access through the 40 
VI Server. The Exported Vis list specifies which Vis are 
exported. To change an entry, the user selects it from the list, 
then types into the text box at the right of the Exported Vis 
list. To specify whether remote computers can or cannot 
access that VI, the user clicks on the Allow Access or Deny 45 
Access radio buttons. The user clicks the Add button to 
insert a new entry after the current selection. The user clicks 
the Remove button to delete the current selection. The user 
clicks and drags an entry to change its position within the 
Exported Vis list. If an entry allows access to Vis, a check 50 
mark appears next to the entry. If an entry denies access to 
Vis, a "cross out" symbol appears next to the entry. If no 
symbol appears next to the entry, the syntax of the entry is 
incorrect. 

Each entry in the list describes a VI name or a VI path and 55 
may contain wildcard characters (see the paragraph below 
on wildcard characters). Entries that contain path separators 
are compared against VI paths, while entries that do not 
contain path separators are compared against VI names only. 
When a remote client tries to access a VI, the server 60 
examines the Exported Vis list to determine whether to grant 
access to the requested VI. If an entry in the list matches the 
requested VI, the server either allows or denies access to that 
VI, based on how that entry is set up. If a subsequent entry 
also matches the VI, its access permission is used in place of 65 
the previous permission. If there is not a VI in the list that 
matches the requested VI, access to the VI is denied. 
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As mentioned earlier, the user can use wildcard characters 
in the Exported Vis list so an entry in the list matches more 
than one VI. The following wildcard characters can be used: 



matches exactly one arbitrary character, except for the 
path separator. 

matches zero or more arbitrary characters, except for 
the path separator. 

together match zero or more arbitrary characters, 
including the path separator. 



If the user wants to match a VI with a name that contains 
a wildcard character, the user must escape that character 
using 'V on the Macintosh and UNIX platforms, and using 

on Windows. 

The following tables shows some examples of Exported 
VI list entries. The examples use UNIX path separators. 



TABLE 1 


Server: TCP/IP Access Entries 




Matches all Vis 


/usr/labview/* 


Matches all Via in the directory 




/usr/labview/. 


/usr/labview/** 


Matches all Vis in the directory 




/usr/labview/ and any of its sub -directories. 


TesLvi 


Matches any VI named "TesLvi". 


* export* 


Matches any VI with a name that contains 




the string "export". 


OK\? 


Matches any VI with the name OK?. 



In FIG. 48 all Vis in the c:\labview\server directory are 
exported. All Vis in the c:\labview\test directory and all its 
sub-directories are exported as well, with the exception of 
the VI c:\labview\test\private.vi. Additionally, any VI that 
begins with the string srvr_ and ends with the string .vi is 
exported. No VI that begins with the string local_ and ends 
with the string .vi is exported, even if it is located within the 
c:\Jabview\server directory. 

The default Exported Vis settings allow access to all Vis, 

3. TCP/IP Access Configuration 

When the user allows remote applications to access the VI 
Server using the TCP/IP protocol, the user should specify 
which Internet hosts have access to the server. To configure 
the clients that have access, the user selects 
Edit»Preferences on the server machine and selects Server: 
TCP/IP Access from the drop down menu. The options 
appear in the Preferences dialog box as shown in FIG. 49. 

Selecting Server: TCP/IP Access allows the user to 
specify which clients can access the VI Server. The TCP/IP 
Access List describes clients that either have access to or are 
denied access to the Lab VIEW server. To change an entry, 
the user selects it from the list, then types into the text box 
at the right of the TCP/IP Access List. The user clicks on the 
Allow Access radio button to allow the client to access the 
server. The user clicks the Deny Access radio button to deny 
the client access to the server. The user clicks the Add button 
to insert a new entry after the current selection, the user 
clicks the Remove button to remove the current selection 
from the list. The user clicks and drags an entry to change 
its position within the TCP/IP Access List. If an address is 
allowed access, a check mark appears next to the entry. If an 
address is denied access, a "cross out" symbol appears next 
to the entry. If no symbol appears next to the entry, the 
syntax of the entry is incorrect. 

When a client tries to open a connection to the server, the 
server examines the entries in the TCP/IP Access List to 
determine whether it grants access to the client. If an entry 
in the list matches the client's address, the server either 
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allows or denies access, based oo how the user set up the 
entry. If a subsequent entry also matches the client's address, 
its access permission is used in place of the previous 
permission. (For example, in FIG. 16 above, a. test.site.com 
in the TCP/IP Access List is allowed access even though the 
list indicates that all addresses ending in .test.site.com are 
not allowed access. See the paragraph on wildcards later in 
this document.) If no entry matches the client's address, 
access is denied. 

An Internet (IP) address, such as "130.164.123.123", may 
have one domain name (such as "www.natinst.com") or 
more associated with it. The conversion from a domain 
name to its corresponding IP address is called name reso- 
lution. The conversion from an IP address to its domain 
name is called name lookup. 

Name lookups and name resolutions are done through 
system calls that access domain name system (DNS) servers 
on the Internet. A name lookup or resolution can fail when 
the system does not have access to a DNS server, or when 
the address or name is not valid. A resolution problem occurs 
when an entry contains a domain name that cannot be 
resolved into an IP address. A lookup problem occurs when 
an entry contains a partial domain name, such as 
"*. natinst.com", and the lookup for the client's IP address 
fails. 

The Strict Checking option determines how the server 
treats access list entries that cannot be compared to a client's 
IP address because of resolution or lookup problems. When 
Strict Checking is enabled, a denying access list entry in the 
TCP/IP Access List that encounters a resolution problem is 
treated as if it matched the client's IP address. When Strict 
Checking is disabled, an access list entry that encounters a 
resolution problem is ignored. 

To specify an Internet host address, the user enters its 
domain name or IP address. The * wildcard can be used 
when specifying Internet host addresses. For example, the 
user can specify all hosts within the domain domain.com 
with the entry *. domain.com. The user can specify all hosts 
in the subnet whose first two octets are 130.164 with the 
entry 130.164.*. The entry * matches all addresses. 

The following table shows some examples of TCP/IP 
Access List entries. 



TABLE 2 


Server: TCP/IP Access 




Matches all hosts. 


testsite.com 


Matches the host whose domain name is 




testsitccom. 


*. site.com 


Matches all hosts whose domain name 




ends with * site.com. 


130.164.123.123 


Matches the host with the [P address 




130.164.123.123. 


130.164.123.* 


Matches all hosts whose IP address starts 




with 130.164.123. 



In FIG. 49 all hosts in the site.com domain have access to 
the server, with the exception of all hosts in the test.site.com 
domain. Additionally, the hosts a.test.site.com, b.test.site- 
.com and 130.164.123.123 have also access to the server. 
The host public.site.com does not have access, even though 
it is in the site.com domain. 

The default TCP/IP Access settings allow access only to 
clients on the server machine. 

It is noted that, if the VI Server runs on a system that does 
not have access to a DNS server, domain name entries 
should not be used in the TCP/IP Access list — requests to 
resolve the domain name or an IP address will fail, slowing 
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down the system. For performance reasons, place frequently 
matched entries toward the end of the TCP/IP Access list. 
Local Client/Server Communication 
When a client on a first computer accesses functionality of 

5 a VI located on the first computer, i.e., accesses a local VI, 
the respective access node, e.g., the call by reference node, 
the invoke node, or the property node, operates to manipu- 
late or access the VI in a similar manner as if the VI were 
in the client graphical program. 

10 FIGS. 50A-50D Client/Server Communication Over a Net- 
work 

FIGS. 50A-50D illustrate operation of a client on a first 
computer accessing functionality of a VI located on a second 
(different) computer. The first computer where the client 

15 graphical program executes is referred to as the client, and 
the second computer where the server graphical program 
(VI) or application exists is referred to as the server. In this 
diagram, the squares on the left represent the client side code 
of Lab VIEW, and the circles on the right hand side represent 

20 the LabVIEW server code. 

Each message that is sent between the client code and the 
server code contains four fields of information at the very 
beginning, or message header: 1) an error code, used in reply 
messages from the server and unused in messages sent from 

25 the client. 2) a message identifier that simply identifies the 
content of the message. 3) a unique identifier that is usually 
used by the client to identify transactions. The server simply 
returns this unique id in the reply for that message. For some 
messages and replies, this field is used as reply information. 

30 4) a message length that contains the number of bytes in any 
extra data that is contained in the message. 

Referring now to FIG. 50A, in order to establish a 
connection, the client sends the first message. This first 
message is basically a "hello" transmitted to the server, and 

35 the server replies with a hello message back. The message id 
indicates that the transmitting device is a client and is saying 
hello. The unique id informs the server as to what protocol 
version the client is using. By exchanging the protocol 
version that each is using, the client code and server code 

40 ensure that the other will understand the messages that they 
send. 

The server replies with a hello message saying either that 
the server is using the same protocol version as the client, or 
the server returns an error and also tells the client what 

45 protocol version the server is communicating with. 

Referring now to FIG. SOB, the Get VI reference opera- 
tion is shown. The Get VI reference always starts with the 
client. The client asks the server for a reference to a VI. The 
most important information that the client transmits to the 

50 server is a path to the VI or a VI name that identifies the VI. 
This information is appended to the end of the message just 
after the message header. The unique id of the message is 
generated by the client in such a way that it can match up the 
reply with the request. The server reply contains this unique 

55 id and, appended to the message header, another unique id 
that is the reference to the server's VI, hereafter referred to 
as the target VI. 

When the client gets a VI reference, the client constructs 
a "stand-in" VI called a proxy callee. A proxy callee is 

60 essentially a stub, i.e., a virtual instrument that contains only 
the most fundamental of data structures representing a 
virtual instrument. Any operation that the client desires to 
perform an the target VI (server VI) goes to the proxy callee, 
and the operation is sent across the network to the server side 

65 and the operation takes place there on the target VI. 

Referring now to FIG. SOC, the Call VI operation is 
shown. As shown, on the client side, the client actually calls 
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the proxy callee. When the proxy callee in the client is called ActiveX Container 

at run time, the code that actually executes is networking The ActiveX container manipulates data on ActiveX 

code that basically takes the arguments to the VI, converts objects. These changes are preferably displayed in the 

them into a well-defined format suitable for transmission container on the front panel. This container allows the user 

over a network connection, and transmits them to the server. 5 to use ActiveX controls and embed documents on the front 

The proxy callee sends the flattened data out across the panel. FIG. 52 illustrates the. 

network stream to the server. The ActiveX container appears as an automation refnum 

On the server side, upon realizing that the client wishes to terminal on the block diagram. This terminal can be wired to 

call the target VI, the server creates another "stand-in" VI, Automation functions and, therefore, control the object 

called a proxy caller VI. This proxy caller VI is used to embedded in the container. If that object has no Automation 

reconstruct the call to the target VI on the server side. It's interface, then the term has an invalid refnum and cannot be 

primary purpose is to simply call the target VI. The server uscd ^ lhe Automation functions. 

code receives the inputs to the target VI call, converts them Xo insert an object int0 tfae front { cont amer, the user 

into the format that is used for normal execution, and copies ^ sdects losct{ ActiyeX Qbject ^ msert Qbject 

tern into the proxy cal er s data space The proxy caller is dkl box a& shown k nG 25 

then executed, and it calls the target VI in the same manner 15 ~ & . t v- * t. 1 j ■ 

, to I wo types or objects can be placed in the container: 

as a normal sub VI call. . , Jr \ , * ™ r A , , 

T , 7 , . . , 7T . . , . iL , . controls and documents. The user can create a new control 

When the target VI completes and returns, the operation , * • ^ • j * * i ^ 

u *u *u j ,7 a i- • _c j n n. ^ , i t ft or document or insert an existing document or control. To 

beneath the dotted line is performed. When the target VI . . , , ~ iL , 4 . 

- . . ... ,i . - 1 create a new control or document, the user selects Create 

finishes, it returns to the proxy caller, which in this example VT , . , \ 4 t , c 

• * u * *^rr ii -ri < ' , /T n f. on New (as shown m FIG. 53) and selects the object type from 

is the target VI proxy caller. The target VI proxy caller on the 20 v «. . , ™ . . 7 . , J 4 '5, lL 

.j . iL , r : i( . . the items listed. To insert an existing document or file, the 

server side receives the return values, converts them into a i . ur > . r „ j-i i_ , \t_ , 

]\ a c j c * i-i r . • • 1 user selects Create rrom File and the dialog changes to that 

well-defined format suitable for transmission over a network shown in FIG 53 

connection and sends them back to the client in a message r™ , ' . * . iL , , , . A it 

■ j j , ii a u • t-t^ r-A^ .t. *. Th e u ser designates the document to insert, and the user 

identified as a return call. As shown in FIG. 50C, the return ^ 7 ^ , t , i 

t1 . , j . i > « * ii_ of can Browse ... to find that document. If the Link option is 

call message includes return parameters which comprise the ^ < . * , 4 . A 4 , . iL - * t 

* * c.Z itj , "wt tl . 11 1 selected, the document is updated when the front panel 

output or the called or target VI. The return call message also t . j . . TJ : 4l _ j t , iT - 1 < *• 

. ; , . t , f. 4 _. T , to object is updated. II the user does not select Link, a static 

mcludes the unique id of the chent VI reference. . c _. , . . , , 

„ 7U tU n , . j t_ ,i i* . .t version of the document is mserted. 

When these parameters are received by the client, the • _* • * i *i_ i * «t 

j«j «ut«* jj. * ii To insert an existing control, the user selects Insert 

client code finds the VI reference and determines the caller n . „, , , u , & , ' . , . ri „ 

associated with this retura call message. TOe client receives 30 Co ^ rol ^alog changes to that shown m FIG. 54 

t . . . • , /> , Ine available obiect types are listed, but the user can add 

these parameters, converts them into the format that is used 4U , 1 , ^. . * y ™ \u * Z 7? T , 

P r , \. , * t 4 . _ . other controls to this list by pressing the Add Control . . . 

for normal execution, and returns the values to the actual , ™, B c A 4 . v 

„ . t . j button. The user can edit the appearance of an ActiveX 

caller on the client side. u . . u . . , .. rj i t ™ 

Referring now to FIG. 50D, for the invoke and property ob J ect ^ ^selecting Edit Object. The apph- 

funcUons, operation is similar to that described above with 35 J*'™ tha ' can edlt ha ' ^ °P ens - ™° ^ «ved 

<* * r-ii- t-> iL • i j , to the container in LabVlbW. 

reference to FIG. 50C. For the invoke and property AUU ... . A , 

P # . . . „ „. ,„ . t 4t _ T i- . Although the system and method of the present invention 

functions, the client is not calling a VI, but rather the chent , . fe , Z , . ..^ r j 

. ^- %rr • i ■ , i j has been described in connection with the preferred 

is getting/setting properties on a VI or invoking methods on ... .... , . . , , . , . . , . t . F 

Vis embodiment, it is not mtended to be limited to the specific 

Property Node 40 ^° rm 561 ^ ort ^ ^ ere ^ Qi 011 ^ e contrar y 5 lt is intended to 

n_ f r j it 4 4 ^, cover such alternatives, modifications, and equivalents, as 

Properties^ — Virtual Instrument Class , . . ' , iL . A 1 

rrn • *u , , T ! ... , i . . ■ can be reasonably included within the spirit and scope of the 

The properties in the VI class which can be get/set by the . ,. , / , u , , , . v 

n J a a u j • tto * * i- c mvention as defined by the appended claims. 

Property node are described in U.S. patent application Ser. What is claimed is* 

No. 08/916,005, referenced above. These properties are set * * . . " , , 4t _ , r 

• j-* j ,t lwic , 4*; 1. A computer-implemented method for creating a grapni- 

ona VI in edit mode through VI Setup and the menu options. 4i , L • ^ . j ^ • < , 

& r r cal program, wherein the method for creatmg the graphical 

FIGS. 51-54: Third Embodiment program operates in a computer including a display screen 

FIGS. 51-54 illustrate a third embodiment where the and a user m ^ device, the method for creating the graphi- 

object node comprises a user interface node which manipu- ca * program comprising: 

lates data on objects comprised in the node. In the preferred 50 creating the graphical program in response to user input, 

embodiment, the user interface object node is an ActiveX wherein the graphical program is created in a first 

container. graphical program development environment, wherein 

ActiveX Front Panel Enhancements said creating the graphical program includes: 

In this embodiment, the graphical programming system, displaying on the screen a first node in the graphical 

e.g., Lab VIEW, includes a new control subpalette for the 55 program in response to user input, wherein the first 

front panel, the Ctls subpalette, which includes two ActiveX node is operable to access capabilities of a software 

controls: ActiveX Container and Active X Variant, as shown object, wherein the software object is not present in 

in FIG. 51. the first graphical program development environ- 

These new controls allow the user to take advantage of the ment; 

ActiveX Container capability, and enhance the interactions 60 configuring the first node to receive information on the 

between LabVIEW and other applications. software object in response to user input; 

ActiveX Variant Control and Indicator wherein, during execution of the graphical program, the 

The ActiveX Variant control and indicator allows passage first node is operable to access the capabilities of the 

of Active X Variant data into LabVIEW, so ActiveX client software object, 

functionality is enhanced. This front panel object is used 65 2. The method of claim 1, 

when ActiveX Variant data is converted to data that Lab- wherein the software object is created in a second pro- 

VIEW can display. gram development environment, wherein the second 
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program development environment is different than the 
first graphical program development environment, 

3. The method of claim 2, 

wherein the second program development environment is 
a text-based program development environment. 

4. The method of claim 1, further comprising: 
creating the software object in a second program devel- 
opment environment, wherein the second program 
development environment is different than the first 
graphical program development environment. 

5. The method of claim 1, 

wherein the software object is operable to execute inde- 
pendently of the graphical program. 

6. The method of claim 1, 

wherein the software object exists prior to said creating 
the graphical program. 

7. The method of claim 1, further comprising: 
executing the graphical program, wherein the graphical 

program is executed by a graphical program execution 
engine; 

wherein said executing the graphical program comprises 

executing the first node to access the capabilities of the 

software object; 
wherein said accessing the capabilities of the software 

object comprises executing the software object; 
wherein the software object executes without use of the 

graphical program execution engine. 

8. The method of claim 1, further comprising: 
executing the graphical program in a first process; 
wherein execution of the graphical program causes execu- 
tion of the software object; 

wherein the software object executes in a second process. 

9. The method of claim 1, 

wherein said creating the graphical program in response 
to user input does not include receiving user input 
specifying text-based programming language source 
code to implement the graphical program; 

wherein the software object is a pre-existing software 
object that was constructed in response to text-based 
programming language source code. 

10. The method of claim 1, 

wherein the graphical program includes a plurality of 
nodes visually indicating functionality of the graphical 
program; 

wherein the software object is not one of the plurality of 
nodes. 

11. The method of claim 1, 

wherein the graphical program includes a plurality of 
nodes visually indicating functionality of the graphical 
program; 

wherein the software object does not implement function- 
ality of any of the plurality of nodes. 

12. The method of claim 1, further comprising: 
compiling the graphical program to produce a first portion 

of executable code; 
wherein the software object comprises a second portion of 
executable code which is independent from the first 
portion of executable code. 

13. The method of claim 1, 

wherein the first node is an object node specifically 
designed to access capabilities of software objects 
external to graphical programs. 
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14. The method of claim 1, 

wherein the computer is a first computer coupled to a 

second computer through a network; 
wherein the software object is stored on the second 

computer. 

15. The method of claim 14, further comprising: 
executing the graphical program, wherein the graphical 

program executes on the first computer; 
wherein said executing the graphical program comprises 
executing the first node to access the capabilities of the 
software object, wherein said accessing the capabilities 
of the software object causes execution of the software 
object on the second computer. 

16. The method of claim 15, further comprising: 
displaying on the screen a user interface panel in response 

to user input for displaying data input to and/or output 
from the graphical program. 

17. The method of claim 1, wherein the method for 
creating the graphical program further comprises: 

arranging on the screen the graphical program including 
said first node. 

18. The method of claim 17, wherein the graphical 
program comprises a plurality of nodes, wherein the method 
for creating the graphical program further comprises: 

arranging on the screen said plurality of nodes, including 

said first node; and 
connecting said plurality of nodes and said first node in 

response to user input to create the graphical program. 

19. The method of claim 18, wherein the method creates 
a graphical data flow program; 

wherein said connecting includes connecting said plural- 
ity of nodes and said first node to provide data flow 
between said plurality of nodes and said first node. 

20. The method of claim 17, wherein the method for 
creating the graphical program further comprises: 

displaying on the screen a user interface panel in response 
to user input for displaying data input to and/or output 
from the graphical program. 

21. The method of claim 20, wherein the method for 
creating the graphical program further comprises: 

arranging on the screen the user interface panel in 
response to user input. 

22. The method of claim 1, further comprising: 
constructing execution instructions in response to said 

graphical program, wherein said execution instructions 
are executable to access said capabilities of the soft- 
ware object; and 
executing said execution instructions, wherein said first 
node accesses said capabilities of the software object 
during said executing. 

23. The method of claim 1, wherein the software object is 
an independent application; 

wherein the first node is operable to perform one or more 
of 1) trigger execution of the independent application; 
or 2) get/set one or more properties of the independent 
application. 

24. The method of claim 1, 

wherein the software object comprises one of: 
an ActiveX object; 
a Java object; 
a C++ object; 
a CORBA object. 

25. The method of claim 1, 

wherein the software object comprises a first method; 
wherein the first node is operable to invoke the first 
method of the software object. 
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26. The method of claim 25, further comprising: 
configuring the first node to invoke the first method of the 

software object in response to user input. 

27. The method of claim 1, 

wherein the software object comprises a first property; 5 
wherein the first node is operable to perform one or more 
of: 

get the first property; 
set the first property. 

28. The method of claim 27, further comprising: 10 
configuring the first node to get/set the first property of the 

software object in response to user input. 

29. The method of claim 1, 

wherein said first node includes an object reference input 15 
for receiving a reference to the software object; 

wherein said configuring comprises connecting said 
object reference input of said first node to receive the 
reference to said software object. 

30. The method of claim 29, 20 
wherein said object node receives said information on 

said software object on said object reference input 
during execution of the graphical program. 

31. The method of claim 30, wherein said configuring 
comprises: 25 

displaying on the screen an object reference node which 

includes an object reference output that provides the 

reference to said software object; and 
connecting the object reference output of said object 

reference node to said object reference input of said 30 

first node. 

32. The method of claim 1, 

wherein said configuring comprises configuring said first 
node with a reference to said software object in ^ 
response to user input. 

33. The method of claim 1, 

wherein the graphical program comprises a diagram por- 
tion and a user interface portion; 
wherein the first node is comprised in the diagram portion. 40 

34. The method of claim 1, 

wherein the graphical program comprises a diagram por- 
tion and a user interface portion; 

wherein the first node is comprised in the user interface 
portion. 45 

35. The method of claim 1, wherein the software object is 
comprised in a server, wherein said configuring comprises: 

displaying on the screen a list of libraries associated with 

one or more servers; 
selecting a library from said list of libraries in response to 50 

user input 

displaying on the screen a list of possible classes from the 

selected library; and 
selecting a class from said list of possible classes in ss 

response to user input; 
wherein said software object is instantiated from said 

class. 1 

36. A computer-implemented method for creating a 
graphical program, wherein the method for creating the 50 
graphical program operates in a computer including a dis- 
play screen and a user input device, the method for creating 
the graphical program comprising: 

creating the graphical program in response to user input, 
wherein the graphical program is created in a first 65 
graphical program development environment, wherein 
said creating the graphical program includes: 
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displaying on the screen an object node in the graphical 
program in response to user input, wherein said 
object node is operable to access capabilities of a 
software object, wherein the software object is exter- 
nal to, and created independently of, the first graphi- 
cal program development environment; 

configuring the object node to receive information on 
the software object in response to user input; 
wherein, during execution of the graphical program, the 

object node is operable to access said capabilities of the 

software object. 

37. A computer-implemented method for creating a 
graphical program, wherein the method for creating the 
graphical program operates in a computer including a dis- 
play screen and a user input device, the method for creating 
the graphical program comprising: 

executing a first graphical program development environ- 
ment application; 

receiving user input to the first graphical program devel- 
opment environment application for creation of the 
graphical program; 

wherein said receiving user input to the first graphical 
program development environment application com- 
prises: 

receiving user input requesting inclusion of a first node 

in the graphical program; 
receiving user input to configure the first node to access 

capabilities of a pre-existing software object; 
wherein, during execution of the graphical program, the 
first node is operable to access said capabilities of the 
pre-existing software object. 

38. The method of claim 37, further comprising: 
compiling the graphical program to produce executable 

code; 

wherein the executable code of the graphical program is 
executable to invoke execution of the pre-existing 
software object. 

39. The method of claim 37, further comprising: 
executing the graphical program; 

wherein execution of the graphical program causes execu- 
tion of the software object; 

wherein the software object executes independently of the 
graphical program. 

40. The method of claim 37, further comprising: 
executing the graphical program in a first process; 
wherein execution of the graphical program causes execu- 
tion of the software object; 

wherein the software object executes in a second process. 

41. The method of claim 37, 

wherein the pre-existing software object was created in a 
second program development environment, wherein 
the second program development environment is dif- 
ferent than the first graphical program development 
environment. 

42. The method of claim 37, 

wherein said receiving user input to the first graphical 
program development environment application for cre- 
ation of the graphical program does not include receiv- 
ing user input specifying text-based programming lan- 
guage source code; 

wherein the pre-existing software object was constructed 
in response to text-based programming language 
source code. 
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43. The method of claim 37, further comprising: 
executing the graphical program, wherein the graphical 

program is executed by a graphical program execution 
engine; 

wherein said executing the graphical program comprises 

executing the first node to access the capabilities of the 

software object; 
wherein said accessing the capabilities of the software 

object comprises executing the software object; 
wherein the software object executes without use of the 

graphical program execution engine. 

44. The method of claim 37, 

wherein the graphical program includes a plurality of 
nodes visually indicating functionality of the graphical 
program; 

wherein the software object is not one of the plurality of 
nodes. 

45. The method of claim 37, 

wherein the graphical program includes a plurality of 
nodes visually indicating functionality of the graphical 
program; 

wherein the software object does not implement function- 
ality of any of the plurality of nodes. 

46. The method of claim 37, further comprising: 
compiling the graphical program to produce a first portion 

of executable code; 
wherein the software object comprises a second portion of 
executable code which is independent from the first 
portion of executable code. 

47. The method of claim 37, 

wherein the computer is a first computer coupled to a 

second computer through a network; 
wherein the pre-existing software object is stored on the 

second computer, 

48. The method of claim 47, further comprising: 
executing the graphical program, wherein the graphical 

program executes on the first computer; 
wherein said executing the graphical program comprises 
executing the first node to access the capabilities of the 
software object, wherein said accessing the capabilities 
of the software object causes execution of the software 
object on the second computer. 

49. The method of claim 37, wherein the graphical 
program comprises a plurality of nodes, wherein the method 
further comprises: 

arranging on the screen said plurality of nodes, including 

said first node; and 
connecting said plurality of nodes and said first node in 

response to user input to create the graphical program. 

50. The method of claim 49, wherein the method creates 
a graphical data flow program; 

wherein said connecting includes connecting said plural- 
ity of nodes to provide data flow between said plurality 
of nodes. 

51. The method of claim 37, further comprising: 
constructing execution instructions in response to said 

graphical program, wherein said execution instructions 
are executable to access said capabilities of the soft- 
ware object; and 
executing said execution instructions, wherein said first 
node accesses said capabilities of the software object 
during said executing. 

52. The method of claim 37, 

wherein the pre-existing software object comprises one 
of: 
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an ActiveX object; 
a Java object; 
a C++ object; 
a CORBA object. 

53. The method of claim 37, 

wherein the software object comprises a first method; 
wherein the first node is operable to invoke the first 
method of the software object. 

54. The method of claim 53, further comprising: 

10 configuring the first node to invoke the first method of the 
software object in response to user input. 

55. The method of claim 37, 

wherein the software object comprises a first property; 
wherein the first node is operable to perform one or more 

15 of: 

get the first property; 
set the first property. 

56. The method of claim 55, further comprising: 
configuring the first node to get/set the first property of the 

20 software object in response to user input. 

57. A memory medium which stores a graphical program 
development environment, wherein the graphical program 
development environment comprises program instructions 
executable to create a graphical program in response to user 

25 input, wherein said creating the graphical program includes: 
displaying on a display screen a first node in the graphical 
program in response to user input, wherein the first 
node is operable to access capabilities of a software 
object, wherein the software object is not present in the 
30 first graphical program development environment; 

configuring the first node to receive information on the 

software object in response to user input; 
wherein, during execution of the graphical program, the 
first node is operable to access the capabilities of the 
35 software object. 

58. The memory medium of claim 57, 

wherein the software object is created in a second pro- 
gram development environment, wherein the second 
program development environment is different than the 
40 first graphical program development environment. 

59. The memory medium of claim 58, 

wherein the second program development environment is 
a text-based program development environment. 

60. The memory medium of claim 57, further comprising: 
creating the software object in a second program devel- 
opment environment, wherein the second program 
development environment is different than the first 
graphical program development environment. 

5Q 61. The memory medium of claim 57, 

wherein the software object is operable to execute inde- 
pendently of the graphical program. 

62. The memory medium of claim 57, 

wherein the software object exists prior to creating the 
55 graphical program. 

63. The memory medium of claim 57, wherein the graphi- 
cal program development environment further comprises 
program instructions executable to manage execution of the 
graphical program; 

60 wherein said executing the graphical program comprises 
executing the first node to access the capabilities of the 
software object; 
wherein said accessing the capabilities of the software 
object comprises executing the software object; 

65 wherein said execution of the software object is not 
managed by the graphical program development envi- 
ronment. 
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64. The memory medium of claim 57, 

wherein said creating the graphical program in response 
to user input does not include receiving user input 
specifying text-based programming language source 
code to implement the graphical program; 5 

wherein the software object is a pre-existing software 
object that was constructed in response to text -based 
programming language source code. 

65. The memory medium of claim 57, 

wherein the graphical program includes a plurality of 
nodes visually indicating functionality of the graphical 
program; 

wherein the software object is not one of the plurality of 
nodes. 15 

66. The memory medium of claim 57, 

wherein the graphical program includes a plurality of 
nodes visually indicating functionality of the graphical 
program; 

wherein the software object does not implement function- 20 
ality of any of the plurality of nodes. 

67. The memory medium of claim 57, wherein the graphi- 
cal program development environment further comprises 
program instructions executable to compile the graphical 
program to produce a first portion of executable code; 25 

wherein the software object comprises a second portion of 
executable code which is independent from the first 
portion of executable code. 

68. The memory medium of claim 57, 

wherein the memory medium is on a first computer 
coupled to a second computer through a network; 

wherein the software object is stored on the second 
computer. 

69. The memory medium of claim 57, wherein the graphi- 35 
cal program comprises a plurality of nodes, wherein the 
graphical program development environment further com- 
prises program instructions executable to: 

arrange on the display screen said plurality of nodes, 
including said first node; and 40 

connect said plurality of nodes and said first node in 
response to user input to create the graphical program. 

70. The memory medium of claim 57, wherein the graphi- 
cal program development environment further comprises 
program instructions executable to display on the display 45 
screen a user interface panel in response to user input for 
displaying data input to and/or output from the graphical 
program. 

71. The memory medium of claim 57, wherein the graphi- 
cal program development environment further comprises 50 
program instructions executable to: 

construct execution instructions in response to said 
graphical program, wherein said execution instructions 
are executable to access said capabilities of the soft- 
ware object; and 

execute said execution instructions, wherein said first 
node accesses said capabilities of the software object 
during said executing. 

72. The memory medium of claim 57, 6Q 
wherein the software object comprises one of: 

an ActiveX object; 
a Java object; 
a C++ object; 

a CORBA object. 65 

73. The memory medium of claim 57, 

wherein the software object comprises a first method; 
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wherein the first node is operable to invoke the first 
method of the software object. 

74. The memory medium of claim 57, 

wherein the software object comprises a first property; 
wherein the first node is operable to perform one or more 
of: 

get the first property; 
set the first property. 

75. A memory medium which stores a graphical program 
development environment, wherein the graphical program 
development environment comprises program instructions 
executable to create a graphical program in response to user 
input, wherein said creating the graphical program includes: 

receiving user input requesting inclusion of a plurality of 

nodes in the graphical program, wherein the plurality of 

nodes includes a first node; 
receiving user input to configure the firsts node to access 

capabilities of a pre-existing software object; 
wherein, during execution of the graphical program, the 

first node is operable to access said capabilities of the 

pre-existing software object. 

76. The memory medium of claim 75, wherein the graphi- . 
cal program development environment further comprises 
program instructions executable to compile the graphical 
program to produce executable code; 

wherein the executable code of the graphical program is 
executable to invoke execution of the pre-existing 
software object. 

77. The memory medium of claim 75, 

wherein the pre-existing software object was created in a 
second program development environment, wherein 
the second program development environment is dif- 
ferent than the first graphical program development 
environment. 

78. The memory medium of claim 75, 

wherein the user input to the first graphical program 
development environment application for creation of 
the graphical program does not include receiving user 
input specifying text-based programming language 
source code; 

wherein the pre-existing software object was constructed 
in response to text-based programming language 
source code. 

79. The memory medium of claim 75, 

wherein the graphical program includes a plurality of 
nodes visually indicating functionality of the graphical 
program; 

wherein the software object is not one of the plurality of 
nodes. 

80. The memory medium of claim 75, 

wherein the graphical program includes a plurality of 
nodes visually indicating functionality of the graphical 
program; 

wherein the software object does not implement function- 
ality of any of the plurality of nodes. 

81. The memory medium of claim 75, wherein the graphi- 
cal program development environment further comprises 
program instructions executable to compile the graphical 
program to produce a first portion of executable code; 

wherein the software object comprises a second portion of 
executable code which is independent from the first 
portion of executable code. 

82. The memory medium of claim 75, 

wherein the pre-existing software object comprises one 
of: 
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an ActiveX object; 

a Java object; 

a C++ object; 

a CORBA object. 
83. The memory medium of claim 75, 
wherein the memory medium is on a first computer 

coupled to a second computer through a network; 
wherein the software object is stored on the second 

computer. 
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84. The memory medium of claim 75, wherein the graphi- 
cal program comprises a plurality of nodes, wherein the 
graphical program development environment further com- 
prises program instructions executable to: 

arrange on the display screen said plurality of nodes, 
including said first node; and connect said plurality of 
nodes and said first node in response to user input to 
create the graphical program. 
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